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, 15 changes were merged. Here are some I thought were interesting from this week.
test: assumeutxo: add missing tests in wallet_assumeutxo.py by alfonsoromanz
In this pull request, Alfonso Romanz tackled adding new functional tests to the wallet_assumeutxo.py file. If you’re not familiar with AssumeUTXO, I would recommend reading this Bitcoin OpTech article.
In the wallet_assumeutxo.py file, there was a TODO that said, “Test loading a wallet (backup) on a pruned node.” This is exactly what Romanz did in this PR with additional cleanup of the test file.Cluster mempool followups by sdaftuar
Last week, we saw the giant PR for Cluster Mempool get merged, so naturally, there would be some follow-up changes. Gloria Zhao mentioned in the main Cluster Mempool Implementation PR to split up the main part of Cluster Mempool and any optimizations and cleanups into separate PRs for easier reviewing.
When quickly looking over the commits of this PR, what I see are mostly removing unused or unneeded variables, using cluster size limits instead of ancestor size limit, doc changes, variable naming changes, and more.log: Use more severe log level (warn/err) where appropriate by maflcko
If you’ve ever worked on a project that had logs spamming your screen, you might have implemented logging levels. This also exists in Bitcoin Core via the LogInfo, LogError, and LogWarning. This makes is so that we don’t need to prepend logs with “Warning: …” or “Error: …”.
In addition to not having to prepend the logging messages, being able to grep the logs to find all the errors or all the warnings, this makes it so all the logs are uniform, and the grep easier to do.
Finally, I know that maflcko has this pull request that has been open for a long time and requires this PR to be merged before being able to continue. So maybe we will see this on a future edition of This Week in Bitcoin.
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.
The
-blockreservedweightstartup option should only affect RPC code, because IPC clients (currently) do not have a way to signal their intent to use the node default (theBlockCreateOptionsstruct defaults merely document a recommendation for client software).Before this PR however, if the user set
-blockreservedweightthenApplyArgsManOptionswould cause theblock_reserved_weightoption passed by IPC clients to be ignored. Users who don’t set this value were not affected.Fix this by making BlockCreateOptions::block_reserved_weight an
std::optional.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
Kernel WG Update (sedited)
sedited: A bunch of PRs on the board waiting for review: https://github.com/orgs/bitcoin/projects/3
Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: Continuing the work in #31132, fuzzing and benchmarks now use real LevelDB in the background for extra realism. We’ve also measured the peak memory usage during reindex-chainstate: so far, it seems that the memory overhead is measurable (almost 100MB peak extra). Once we’re close to the finish line, we can discuss whether we should do anything about it (e.g., we could lower the default dbcache size or try to reduce memory usage in other ways to compensate). We still have to gather thorough flame graphs to understand the new usage patterns and see where the new bottlenecks will be after the change. We’re also comparing how SSD and HDD are affected by different concurrency levels - these take really long, we don’t have definitive results yet. We’ve also investigated whether we could avoid complete memory reallocations during IBD (after sync we need to fully release the memory), but it seems to slow down IBD so much (up to 3x on some platforms). Most likely this is because it forces each block to flush after the first one, since we’re in a constant critical memory state if we don’t reallocate (it behaves the same if we completely remove the reallocation). We will investigate if this is because of the Pool Allocator introduced in #25325 and if it’s still optimal to have it after the input fetching optimizations above. Reviews and fuzzing are still welcome, and in the meantime #30442 and #33602 would help make some progress on the above.
Silent Payments WG Update (Novo__)
sipa: not really a workgroup member, but i note this relevant ML discussion: https://groups.google.com/g/bitcoindev/c/bP6ktUyCOJI
stickies-v: thanks sipa! we haven’t had updates from the SP WG in quite a while so I suggest archiving this WG until one of the champions requests to activate again. lmk if anyone doesn’t agree with this
abubakarsadiq: From Novo__I have rebased https://github.com/bitcoin/bitcoin/pull/32966 so it now tracks https://github.com/bitcoin-core/secp256k1/pull/1765. https://github.com/bitcoin-core/secp256k1/pull/1765 still needs review. The biggest issue is the worst case scanning performance, theStack and W0xlt have produced working solutions with tradeoffs that are being verified by benchmarks. Reviews are welcome!
Cluster Mempool WG Update (sdaftuar, sipa)
sipa: Cluster mempool followups (33591) were merged, i’d encourage anyone to run with it, play around with the new RPCs, see if logging makes sense, etc. Next up for review is my #32545, which may end up being split into multiple PRs based on review.
Stratum v2 WG Update (sjors)
no response
Net Split WG Update (cfields)
cfields: Continuing to work on the initial PR to move some things into Peer. Got some nice feedback from AJ on the meta issue (#33958) that I’m working on a response to as well. That’s about it, not much to see yet.
_aj_: (in working on that response, i finally got the bip324 short message type update idea from 3 years ago implemented which had been in my backlog)
A short update on BIP 54 / Consensus Cleanup work (darosior)
darosior: Not a Bitcoin Core specific topic, but one that i think could be interesting to people here. As you know i’ve been working on the Consensus Cleanup proposal for over two years now. After Matt’s previous attempt in 2019, i spent the end of 2023 and much of 2024 researching the best mitigations for each issue. We published a BIP in early 2025, and there is now an implementation for review at Bitcoin Inquisition. The test vectors were also recently merged in the BIP repository.
Murch[m]: Great, what do you see as the next steps?
stickies-v: https://github.com/bitcoin-inquisition/bitcoin/pull/99
darosior: So if anybody is interested in helping moving things forward, this is getting to the stage where i could use more eyes on the implementation
dergoegge: Why in inquisition and not in the main repo?
More discussion was done on this topic read more in the meeting in minutes.
why is #33723 not merged yet (dergoegge)
stickies-v: it does look like there is pretty overwhelming support for the change, and sufficient time for feedback/recourse?
sedited: have changes to the seed list been backported historically?
sipa: i haven’t commented myself, because as a DNS seed operator myself i feel sort of conflicted, but i do agree it looks like support for the change is overwhelming
fjahr: I guess under normal circumstances the runner of the seed would be contacted and asked for a statement. Did anyone try to reach out? (I haven’t looked at this at all)
There is more conversation in the meeting in minutes
For the full log, check the meeting in minutes
Releases
No major releases
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
If there are any comments, suggestions, or errors, do not hesitate to reach out or comment
 | A guest post by
|