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, 26 changes were merged. Here are some I thought were interesting from this week.
wallet/rpc: fix listdescriptors RPC fails to return descriptors with private key information when wallet contains descriptors missing any key by Eunovo
Currently,
listdescriptors [private=true]will fail for a non-watch-only wallet if any descriptor has a missing private key(e.gtr(),multi(), etc.). This PR changes that while making surelistdescriptors [private=true]still fails if there no private keys. Closes #32078
This change may be out of my understanding but from quickly overlooking it seems that the listdescriptors fails to return private key info if any keys are missing. This may still be useful because a user might want to get some of their keys when using tr(), multi() or others.
This still fails if ALL keys are missing.merkle: pre‑reserve leaves to prevent reallocs with odd vtx count by l0rinc
l0rinc has been at it again with the optimizations to Bitcoin Core this time to make ComputeMerkleRoot more efficient by optimizing the way it uses memory.
The way this is done is by pre-reserving vector capacity to account for odd-count duplication. Happens only when a block has an odd transaction counts which accounts for roughly half of the created blocks.
The memory profiling l0rinc did shows a 50% reduction in peak allocation. This is a win for all Bitcoin Node runners constructing blocks with an odd number of transactions.util: Add some more Unexpected and Expected methods by maflcko
Maflcko made a PR previously which added util::Expected. This is an expansion to that change because reviewers requested additional member functions. From what I see in this PR it just adds the new functions but does not use them just yet.
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.
bitcoin-cli uptimewas derived from wall-clock time, so it could jump by large amounts when the system clock is corrected afterbitcoindstarts (e.g. on RTC-less systems syncing NTP).
This breaks the expectation that uptime reflects process runtime.
To fix this he suggests
Compute uptime from a monotonic clock so it is immune to wall-clock jumps, and use that monotonic uptime for the RPC.
GUI startup time is derived from wall clock time minus monotonic uptime so it remains sensible after clock corrections.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
16:01:57 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:03 <dergoegge> nothing from my side16:02:18 <fjahr> #topic Kernel WG Update (sedited)
16:02:26 <sedited> stickies-v opened a PR for splitting up higher and lower level logging functionality and exposing richer logging information in the kernel API: https://github.com/bitcoin/bitcoin/pull/34374
16:04:10 <sedited> alexanderwiederin presented some work using a copy-on-write CChain replacement for removing the need to lock cs_main in various small rpc calls (i.e. getblockcount). Still WIP, but can be viewed here: https://github.com/alexanderwiederin/bitcoin/commits/chain-concurrency/
16:05:29 <sedited> I've also resurrected my branch for an abstract block store, though I'll hold off on submitting a PR for the near future.16:05:48 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:05:50 <l0rinc> Started measuring varops budgets on the benchmarking suite of different nodes for the Great Script Restoration proposal.
16:06:00 <l0rinc> We found some bugs in the current benchmark (a few missing ops such as LSHIFT/RSHIFT and an always-empty SUBSTR) so we’re remeasuring everything.
16:06:14 <l0rinc> And opened a Coins Cache Cleanup tracker issue to help reviewers piece together the structure for the UTXO handling PRs #34280
16:06:15 <corebot`> https://github.com/bitcoin/bitcoin/issues/34280 | Coins Cache Cleanup checklist · Issue #34280 · bitcoin/bitcoin · GitHub
16:06:30 <l0rinc> We finally have proper native Windows benchmark results for https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3767758819: the ~30% speedup reproduces on GCC there as well.
16:06:40 <l0rinc> andrewtoth?
16:07:08 <andrewtoth> No update from me. More review on #31132 is welcome. It looks like it’s faster on every platform.
16:07:12 <corebot`> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads 3x faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub16:07:24 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:08:07 <sipa> Priority remains #34257, which I welcome more conceptual comments on, but I also think it’s ready for review.
16:08:09 <corebot`> https://github.com/bitcoin/bitcoin/issues/34257 | txgraph: deterministic optimal transaction order by sipa · Pull Request #34257 · bitcoin/bitcoin · GitHub
16:08:21 <sipa> That’s it for me, I think.16:08:51 <fjahr> #topic Net Split WG Update (cfields)
16:09:06 <cfields> No update this week.16:10:16 <fjahr> Anything else to discuss?
16:11:11 <abubakarsadiq> I did some work on that touches cluster mempool primarily modifying GetMainStagingDiagram to populate refs https://github.com/bitcoin/bitcoin/compare/master...ismaelsadeeq:bitcoin:01-2026-detect-fee-increase-cleanup it’s useful to compute chunk Id after mempool update. I am planning to use chunk Id in package aware fee estimator and block template cache, I have a wip branch that uses these refs. Not sure whether I
16:11:11 <abubakarsadiq> should combine open this as standalone or combine the branch above with changes that actually use it cc sipa
16:12:35 <abubakarsadiq> This branch is ready I think, I’ve fuzzed it for a day. But the other branch is not ready yetFor the full irc meeting be sure to read the meeting in minutes
Releases
No releases this week
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