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, 16 changes were merged. Here are some I thought were interesting from this week.
wallet: fix unnamed legacy wallet migration failure by furszy
Earlier this week, there was a notice not to migrate any legacy (BDB) wallets on v30.0 and v30.1. This is because there is a rare chance that when migrating Bitcoind, it will delete all the wallets on the node.
This would result in a loss of funds if the user did not back up their wallets.
This PR fixes the issue and was backported. The reason this happened was that a change intended to fix something else inadvertently produced this issue.wallet: warn against accidental unsafe older() import by Sjors
This is just a warning error when a miniscript older() import is used. This is because it allows relative height and time locks, which have no consensus meaning in BIP 68 and BIP 112. This is used by some protocols, but is not safe when used unintentionally because older(65536) is equivalent to older(1). This can obviously cause issues, so it makes sense to notify the users so they know they are using something that can unintentionally do things they do not want.
refactor: Let CCoinsViewCache::BatchWrite return void by sedited
Why would you want a function that is supposed to return a boolean to always return true? Well, that was the case for this change. BatchWrite always returned true if called from a backend cache.
So what sedited did was make it return void and thus allowed more simplifications. Like simplifying dead error handling code.
As it says in the title, it is a refactor, so it didn’t modify any functionality but instead made the code cleaner and simpler.
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 goal of the PR is to handle failures in a controlled way. Just so the process can automatically restore the original wallet without requiring user manual intervention.
The covered cases are:
During DoMigration(): There are methods that can throw exceptions and abruptly abort the process. Instead of crashing (GUI) or returning a generic exception, we now will catch and return the error gracefully. This lets the process restore the original wallet automatically.
Trying to migrate a wallet in a read-only directory throws a filesystem exception and skips cleanup. Now the process will fail gracefully with a clear error msg, and automatically restore the original wallet.
Any failure during MigrateToSQLite requires user manual intervention. Now the original wallet db will remain untouched, and only be updated once the sqlite db creation fully succeeds.
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 waiting for review on the project board: https://github.com/orgs/bitcoin/projects/3
Some progress is being made on experimenting with copy-on-write datastructures, janb84 has been running some preliminary benchmarks for replacing the current CChain with such a structure.
Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #33866 was merged, so we rebased the related PRs:
#34132 - the extra error catcher cache layer was inlined to simple call-site try/catch
#34124 - CCoinsView acted as part-interface, part empty implementation - split it into a pure interface and an empty implementation.
And a PR was split off from #33018:
#34207 - GetCoin() is an interface for querying the UTXO set, so production implementations should only ever return unspent coins - adjusted tests to make them more realistic and exercise cases that can actually happen.
There’s also PR now for untimed setup phase for nanobench: #34208
Two PRs were split off from #31132 since they can be reviewed and merged independently - I’ll let andrewtoth expand on those.andrewtoth: We measured #31132 in a cloud environment with network connected storage, and it is >3x faster reindex-chainstate https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3678847806.
It is also faster connecting blocks at tip during steady state. It has been thoroughly fuzzed, and we split out two other PRs #34164, #34165 from it that could have small benefit on their own (and would help make #31132 easier to review).
We’re in the process of measuring windows but having some inconsistent results.
Review on the split out or main PRs are welcome. That’s it from me, thanks.
Cluster Mempool WG Update (sdaftuar, sipa)
sipa: main PR to review is #34023, which optimizing the cluster linearization algorithm, after it was replaced by SFL in 32545
there is some ongoing discussion that may use some conceptual input on #33335
the PR there proposes introducing more randomness for sorting equal-feerate transactions and chunks, to fix a privacy leak (reveal information about the order transactions were received)
but randomness also has downsides in terms of non-predictability, worse block propagation, and ability to monitor behavior on the network
so i’m considering (and implementation) and alternative that makes the ordering deterministic; PR forthcoming
Net Split WG Update (cfields)
cfields: I’ve spent this week profiling and benchmarking a few assumptions (send/receive buffer sizes, corking behavior, etc) in our net code after the chacha20 speedups to ensure that the net split doesn’t bake in any bad assumptions. Thankfully things look quite balanced, so I’m setting that aside and continuing with the manual code movement. Not much to see yet.
Fuzzing WG Update (dergoegge)
dergoegge: I think I mentioned last meeting that I’m writing a blog post series on fuzzamoto
The first part of that is out now: https://brink.dev/blog/2026/01/07/fuzzamoto-introduction/
maintainer nomination (glozow)
glozow: I’m nominating TheCharlatan aka sedited to be a maintainer. He is a reliable reviewer who has worked extensively in critical areas of the codebase, thinks carefully about what we ship to users and developers, and understands the technical consensus process well.
I’ve spoken with him and the other maintainers already, and hope that the rest of you agree he is well-suited for the role. Please speak freely with your concerns and/or support.
A bunch of Acks
fee estimation improvement
abubakarsadiq: I opened a #34075, which attempts to fix the ancient #27995 issue with a mempool-based fee estimator that only lowers the Block Policy Estimator.
Empirically, I observed a 73% success rate with 0% overestimation, and 26% underestimation with this approach. I did some refactors to enable these. See PR op for more details.
Bringing this here to request feedback on the approach and the assumption there.
(ATT)ACKs
l0rinc: I would also like your feedback on a different topic, since we saw fake ACKs being spread around - we could adjust the DrahtBot ACK summary with avatars and maybe italics for members to avoid impersonations. And while we’re touching this, ryanofsky suggested we add links to all acks, not just the last one. Your feedback is welcome in https://github.com/maflcko/DrahtBot/pull/72
Some discussion on how to mitigate the fake ACKs problem
For the full discussion checkout the Meeting in Minutes
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
|