Bitcoin Core 31.0 RC1 Released with Cluster Mempool Rewrite

On March 12, 2026, Bitcoin Core released v31.0rc1, the first release candidate for the upcoming Bitcoin Core 31.0 major release. This is a landmark release that includes cluster mempool, a fundamental architectural redesign of how Bitcoin manages unconfirmed transactions.

Two years in the making since its initial proposal in May 2023, cluster mempool rewrites the logic that determines which transactions get mined, evicted, or replaced. The result is a mempool that better aligns with miner incentives, eliminates long-standing quirks, and opens the door for future improvements.

Here’s what changed and why it matters.

What cluster mempool fixes

Bitcoin’s mempool is the waiting room for unconfirmed transactions. Before cluster mempool, Bitcoin Core tracked these transactions using ancestor and descendant feerate sorts. This approach had three problems:

Eviction could remove transactions that would actually be mined. When the mempool was full, the eviction algorithm could boot out transactions that would have been included in the next block. That’s backwards.

Mining and eviction weren’t symmetric. The mining algorithm was more sophisticated than the ancestor feerate sort used for eviction, creating distortions.

RBF rules didn’t align with miner incentives. Replacement-by-fee logic could accept replacements that were actually worse for miners.

Cluster mempool solves these problems by organizing related transactions into clusters and maintaining a total ordering based on chunks (groups of transactions that will be mined together). This ordering is used symmetrically for mining, eviction, RBF validation, and transaction relay.

How it works

Under cluster mempool, transactions are grouped by parent-child relationships into clusters. Each cluster can contain up to 64 transactions and 101 kB of virtual size. This replaces the old limits of 25 ancestors, 25 descendants, and 101 kB total.

Bitcoin Core now orders transactions by the feerate at which they’re expected to be mined, considering the full “chunk” of related transactions. This chunk-based ordering determines what gets mined first, what gets evicted when the mempool fills up, and whether a replacement transaction actually improves the mempool.

The technical implementation uses a spanning-forest linearization algorithm (merged in Bitcoin Core #32545 in January 2026) that can linearize all observed clusters of up to 64 transactions in tens of microseconds. Fast enough to run in real time.

What changed for users

Most changes are transparent, but a few behaviors shift:

New cluster limits. The 25 ancestor / 25 descendant limits are gone, replaced by cluster limits of 64 transactions and 101 kB. A cluster includes all transactions connected by any parent/child relationships.

Better RBF. Replacement-by-fee validation now only accepts replacements if the resulting mempool’s feerate diagram is strictly better than before. This eliminates all known cases where replacements could make the mempool worse off.

CPFP carve-out removed. The old CPFP carve-out exception (which allowed one extra child transaction to bypass descendant limits) is gone. Users who need similar functionality should use TRUC (v3) transactions with sibling eviction instead. This particularly affects Lightning Network channel management.

New RPCs. Two new commands let you inspect the mempool’s cluster structure: getmempoolcluster and getmempoolfeeratediagram. The existing getmempoolentry now includes chunk size and chunk fees.

Private transaction broadcast

Alongside cluster mempool, Bitcoin Core 31.0 introduces a major privacy feature: private transaction broadcast via Tor or I2P.

A new -privatebroadcast option for the sendrawtransaction RPC broadcasts transactions only via short-lived Tor or I2P connections. This hides your IP address and geolocation from the network, preventing transaction linkability.

Each broadcast uses a separate connection, making it much harder to trace transactions back to their originator. This feature was merged in Bitcoin Core #29415 after years of development.

Complementary RPCs getprivatebroadcastinfo (view queue) and abortprivatebroadcast (cancel) give you control over the broadcast queue.

Other notable changes

Fee estimation goes lower. The minimum tracked fee rate dropped from 1 sat/vB to 0.1 sat/vB, matching the node’s default minimum relay fee. This means the estimator can now return sub-1 sat/vB estimates when sufficient data exists. Note that restarting a node with this change invalidates previously saved estimates in fee_estimates.dat.

Package relay expansion. Bitcoin Core now allows parent transactions with zero fees (or below minimum relay fee) in 1-parent-1-child package relay, even for non-TRUC transactions. Previously this was restricted to TRUC transactions only.

More memory by default. The default database cache (-dbcache) increased from 450 MiB to 1024 MiB on systems with at least 4 GiB of RAM. This improves performance but uses more memory. Users can maintain the previous behavior with -dbcache=450.

New REST endpoint. /rest/blockpart/<hash>.<format>?offset=<X>&size=<Y> lets you fetch byte-ranges of blocks.

Removed features. The -paytxfee option and settxfee RPC (deprecated in 30.0) are now removed. The -maxorphantx option is gone. The tor network specification is removed (use onion instead).

Who should test this

Bitcoin Core release candidates undergo extensive community testing before final release. This one matters for:

Node operators. Cluster mempool affects every Bitcoin Core node.

Miners. Improved block template construction and fee optimization.

Wallet developers. RBF behavior changes and cluster size limits affect transaction construction.

Lightning operators. Removal of CPFP carve-out affects channel management. Migrate to TRUC transactions.

Privacy-focused users. The new private broadcast feature changes the game for transaction submission.

Testing focus areas include mempool behavior under load, RBF replacement edge cases, fee estimation accuracy, private broadcast functionality (requires Tor/I2P), and the upgrade path from v30.x.

Binaries are available at bitcoincore.org, and the work-in-progress release notes are on the Bitcoin Core DevWiki.

Final release timing depends on RC testing results. If history is a guide, expect several weeks to months of testing before the final v31.0 release.

Sources

Bitcoin Core v31.0rc1 GitHub Release, Bitcoin Core 31.0 Release Notes Draft, Bitcoin Core #27677: Cluster mempool proposal, Bitcoin Core #32545: Spanning-forest linearization, Bitcoin Core #29415: Private broadcast, Bitcoin Optech - Cluster Mempool. Data/status as of March 12, 2026.