This week in Bitcoin Core

Merged PR’s

• Cluster mempool by sdaftuar
  Big news, as this is a giant pull request that has been a long time coming. The link to this PR is actually not the original as PR #28676 was opened in Oct 2023, but was closed, as when you opened the link, it would take a while for all the comments to load.
  Nonetheless, this proposal is to swap out the current mempool for a better one that splits connected transactions into clusters, which are then linearized to try and optimize for selecting the highest fee rate subset of the cluster. This is all done through a new class named TxGraph, which handles the partitioning.
  That’s cool and all, but why even make the upgrade? Good question, audience member! This change drops the ancestor and descendant limits, meaning that you can chain txs to your heart’s content. Cluster mempool is also more efficient at picking out the most profitable blocks to mine. In turn, this will make mining more efficient and force miners to use the cluster mempool algorithm, as it will be most efficient. There are other benefits, but this is not the place to list them all out.
  read more: An overview of the cluster mempool proposal
• doc, clarify and cleanup macOS fuzzing notes by dergoegge
  Some docs are for fuzzing on macOS, but are not officially maintained. Personally, I’ve experienced this and had trouble getting my Intel-based MacBook to run the fuzz test suite.
  This change consolidates the docs for fuzzing on macOS to one location and also discloses that it is not officially maintained by Bitcoin Core.
• kernel, add btck_block_tree_entry_equals by stickies-v
  If you don’t understand pointers, this change might be a bit confusing. But if you do, it is intuitive. Basically, what is going on is that when we check if two BlockTreeEntrys are equal, we do a comparison based on height and block hash. Instead, we can check if they have the same pointer (ie, the same block). With this in mind in this PR stickies-v introduces an overload for the == method for BlockTreeEntry.

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.

• test, Ignore error message give from python because of PYTHON_GIL by kevkevin
  Don’t mind me writing about my own PR :). This change is because of Python 3.14.0t because it throws an error for the package pycapnp. After all, it does not support free threading. In the Bitcoin Core test suite this is not a problem since the tests are run in a single thread, so the solution for this pull request is to ignore the error message given from Python because it would pass either way.
  The real solution would be to update the pycapnp package to support free threading. This would remove the TODO that I have added in the PR. This change already has one crACK, it is waiting for additional reviews.

IRC meeting notes

• Fuzzing WG Update (dergoegge)
  • dergoegge: no update
• Kernel WG Update (TheCharlatan)
  • sedited: who’s TheCharlatan? :D
  • sedited: Open PRs for your consideration on the project board: https://github.com/orgs/bitcoin/projects/3
  • sedited: Some good progress reported over the past week with standardizing tests across language bindings.
  • stickies-v; the test project can be found at https://github.com/stringintech/kernel-bindings-tests fyi
• Benchmarking WG Update (l0rinc, andrewtoth)
  • l0rinc: The tx input cache-warming PR evolved from an InputFetcher helper (where the parallelism happened before ConnectBlock was called) to CoinsViewCacheAsync, a multithreaded CCoinsViewCache subclass whose worker threads run in parallel with ConnectBlock itself. For now the async view uses a fixed worker thread count of 4. The workload is primarily I/O-bound on DB latency rather than CPU-bound, so 4 workers already hide most of the latency and it simplifies the implementation. If needed we can make this configurable or tie it to -par later. This way the I/O-bound work runs in parallel with the CPU-bound validation work, and the preliminary results are very encouraging: on a Raspberry Pi 5 the best -reindex-chainstate so far is about 7.3 hours with -dbcache=4500 and about 7.7 hours with the default 450 MB, roughly 36% and 46% faster than the current single-threaded baseline. The new implementation has been fuzzed for several days - it would be good to get some more eyes on it. For broader context, this should also play well with other orthogonal changes we’re working on, such as #30442, #33602, and #32497, and a few ideas that don’t have PRs yet, for example: * a simpler SipHash variant we could use in the UTXO cache, exploiting the fact that the key is already a hash; * a follow-up to #28280 that would reduce the doubly linked list to a singly linked one: we’d do the compaction (non-dirty fresh-spend removals) before BatchWrite in amortized constant time, likely allowing ~10% more elements in the cache; * undoing the noexcept optimization from #16957, which doesn’t seem to help anymore and would likely speed up IBD by another ~2–4%; * skipping all ReallocateCache calls during IBD.
• Cluster Mempool WG Update (sdaftuar, sipa)
  • sdaftuar: cluster mempool was merged! thanks all. there’s a followups PR I’m working on with various doc and code cleanups, and we’ll want to get sipa’s SFL PR merged before the next release.
  • sipa: the PRs being #33591 and #32545
  • sdaftuar: it’d be helpful to get a lot of eyes on docs, rpc output, etc to get things as polished as possible before release
  • sipa: i think it’s worth mentioning that this is probably the time to start thinking/bikeshedding over things like documentation changes and RPCs etc
• Stratum v2 WG Update (sjors)
  • Sjors[m]1: I’m currently working on a refactor of block creation startup argument parsing and the various structs involved. PR soon(tm). I’m running #33922 on a well connected node for a while to see how the mempool weather impacts the block template memory footprint. That’s for transactions outside the mempool that we still hold on to. See chart in that PR for an early result. My guess is that under normal circumstances miners can aggressively request updated templates and it’s not going to cause issues. We do need a way to handle irregular circumstances, probably just FIFO deleting templates.
• Net Split WG Update (cfields)
  • stickies-v: cory is away this week, but he asked to relay this message: “See new meta-issue #33958. Finally getting going. Next week I intend to work on moving necessary CNode state to Peer. Specifically, the lowest hanging fruit”

Releases

• No major releases