This week in Bitcoin Core
Bitcoin Core contributor kevkevin covers some of the latest updates...
Hello 👋 folks, I’m kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo. Here’s what I found notable.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, 8 changes were merged. Here are some I thought were interesting from this week.
wallet: Set descriptor cache upgraded flag for migrated wallets by achow101
There is currently a descriptor cache upgraded flag for newly created wallets. For migrated wallets, this flag was not being set when migrated. So to avoid an unnecessary upgrade, this change adds the flag to any migrated wallets.
achow101 mentions that this would be set when the wallet is reloaded, but this should also be done on the get-go.rpc: fix getblock(header) returns target for tip by Sjors
In the getblock and getblockheader RPC calls, a target field was added. The issue was that when you called the RPC, it would sometimes use the incorrect tip value.
This was missed in the functional tests because regtest does not have a difficulty adjustment, so this PR creates the fix and also expands the test to cover mainnet by modifying the mining_mainnet.py file.
fuzz: reduce iterations in slow targets by marcofleon
If you are familiar with how GitHub Actions works, you might know about the CI that is run after someone opens a PR. Ideally, you would want this to run relatively quickly so that a maintainer can review and then merge your changes. This is because most people would rather wait for the CI to finish running before merging. After all, it can create issues.
Well, this change makes it so some known fuzz tests that take a while to run should have fewer iterations. This makes sense because the fuzzing GitHub actions are usually the last ones to finish, and it is most likely because of these targets. This should improve the time to getting a green checkmark on your PR
Open PR’s
There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.
docs: Undeprecate datacarrier and datacarriersize configuration options by bitschmidty
While this change is just a doc change, it may not seem super important, but it sets forth a precedent that Bitcoin Core will not delete the datacarrier and datacarriersize config values. As they are currently marked as deprecated, which means that in the future they can be deleted. One of the main reasons is that many current Bitcoin Core users want to continue to use these options.
Many current Bitcoin Core users want to continue using this option
This statement is based on public postings from many Bitcoin Core users and not a formal survey. AJ Towns’ observation from #32406 that “for now there seem to be a bunch of users who like the option” has only become more apparent in the months since.
What do you think? Post in the comments below if we should keep or deprecate these options?
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
MuSig2 WG Update (achow101)
achow101: #29675 is still the pr to review, and I’ve been addressing comments on it
30.0
achow101: there’s still a couple things in the milestone: https://github.com/bitcoin/bitcoin/milestone/72, and we tagged rc2 yesterday, so that should be uploaded soon
marcofleon: I’ve been running fuzzamoto on it (v30.0rc1) for a while now, no crashes/bugs so far
cfields: I stumbled upon libmultiprocess#215 this week and imo it should get a quick fix if miners are going to be using it for v30
l0rinc: I ran multiple IBDs with different args on different platforms for v30 (rc1 or master), they all passed
cfields: achow101: after the usual updates, I’d like to make a quick announcement about some of the net projects I’ve been working on.
net projects (cfields)
cfields: Just wanted to give a quick update... I’ve had my head down for a few months now working on a logical separation between net and net_processing. I now have a quick/dirty branch that illustrates what needs to be done for that to happen. I intend to start cleaning that up and putting together a writeup of my proposed architectural changes and the reasons behind them next week… But more interestingly, with that done, I realized that I was 90% of the way to being able to split p2p out of bitcoind completely, so I went ahead and did that too :). Using the (really cool, btw) multiprocess stuff, I’ve been able to hack up a fully-functional multiprocess bitcoin-p2p, which isolates all p2p/network activity to a separate process.
For the full log, check the meeting in minutes
Releases
v30.0rc2 is out. If you have the chance, please give it a test.
This is the testing guide.
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
 | A guest post by
|