Rewards Hub 
Bitcoin Core v31.0rc4 landed on testnet on April 11, 2026, and it carries the biggest architectural change to Bitcoin's transaction handling in years. The release candidate follows v30.2 and introduces cluster mempool, a redesign that organizes unconfirmed transactions into bounded groups of up to 64 transactions or 101 kilobytes, replacing the topology-limited structure that Bitcoin nodes have used since the early days. Alongside that, v31 adds an option for nodes to broadcast transactions exclusively through Tor or I2P, meaning your IP address never touches the clearnet when you send a transaction.
These are not cosmetic changes. Cluster mempool directly affects how miners build blocks, how wallets estimate fees, and how complex transaction packages (think batched payments or Lightning channel closures) get prioritized. Tor-only broadcasting closes a surveillance gap that chain analysis firms have exploited for years. Here is what each change actually does and why it matters if you run a node, mine, or simply send Bitcoin transactions.
What Cluster Mempool Actually Changes
The mempool is where unconfirmed transactions wait before a miner picks them up and includes them in a block. Bitcoin Core has managed this pool for over a decade using ancestor and descendant limits that cap how many related transactions can chain together. The current default allows a maximum of 25 ancestors or 25 descendants per transaction, and the enforcement logic checks each transaction individually against these limits.
The problem is that individual limits create blind spots. When a parent transaction has 10 children and each child has its own fee rate, the node has to evaluate each relationship independently to figure out which combination of transactions would generate the most fees in a block. The math gets expensive fast, and in practice, Bitcoin Core has relied on approximations that sometimes leave money on the table for miners and produce fee estimates that overshoot for users.
Cluster mempool replaces this approach with a different organizing principle. Instead of tracking ancestor and descendant chains, v31 groups related transactions into clusters. Each cluster has a hard ceiling of 64 transactions and 101 kilobytes by default. Within a cluster, the node sorts transactions into chunks ordered by fee rate, which means the highest-paying combinations float to the top without requiring the expensive per-transaction ancestry calculations.
The result for miners is more accurate block templates. When a miner calls getblocktemplate on a v31 node, the response reflects a tighter optimization of which transactions to include for maximum revenue. The result for regular users is better fee estimation, because the node can see the actual competitive ordering of transactions rather than approximating it through ancestor limits.
Why This Matters for Transaction Packages
If you have ever done a CPFP (child-pays-for-parent) transaction to unstick a low-fee payment, you have dealt with the limitations that cluster mempool addresses. Under the old system, bumping a stuck transaction required the wallet to figure out if adding a high-fee child would push the ancestor chain past the 25-transaction limit. If you were already deep in a chain of unconfirmed transactions, the bump could get rejected entirely.
Cluster mempool handles these scenarios more gracefully because it evaluates the entire cluster as a unit. A parent transaction with a low fee rate and a child with a high fee rate get sorted together, and the combined fee rate of the chunk determines its position in the block template. This is particularly relevant for Lightning Network channel closures, which often produce multi-transaction packages that need to confirm together or not at all.
Batched exchange withdrawals also benefit significantly. When an exchange sends one transaction that pays 200 recipients and some of those recipients immediately spend their outputs, the resulting chain of transactions previously risked hitting descendant limits. Under cluster mempool, the entire related group stays organized within the 64-transaction, 101-kilobyte cluster boundary, and the node handles the fee-rate sorting internally rather than forcing wallets to work around topology constraints.
Tor-Only Broadcasting and Why Privacy Needed a Fix
When you broadcast a Bitcoin transaction from a standard node, your IP address is attached to the initial relay. Chain analysis companies run thousands of listening nodes specifically to catch this moment. If they see your IP address broadcast a transaction before any other node, they can probabilistically link that IP to that transaction and, by extension, to your wallet addresses.
Bitcoin Core has supported Tor and I2P connections for years, but until v31, there was no way to restrict transaction broadcasting exclusively to anonymity networks. Your node might connect to Tor peers and clearnet peers simultaneously, and the first relay could go out over either connection type. The new -onlynet=onion and -onlynet=i2p options in v31 let node operators force all outbound transaction broadcasts through Tor or I2P only, so no clearnet peer ever sees the originating relay.
This is not about hiding transactions themselves, which are publicly visible on the blockchain regardless. It is about severing the link between your network identity (IP address) and your transaction activity. For users in jurisdictions with aggressive financial surveillance, or for anyone who takes the "financial sovereignty" promise of Bitcoin seriously, this is a meaningful upgrade. And it works at the protocol level rather than requiring users to configure external VPNs or proxy setups that most people get wrong.
The timing is worth noting. Chainalysis and similar firms have expanded their node-monitoring networks significantly over the past two years, with some estimates putting the number of surveillance relay nodes in the thousands across North America and Europe. The previous workaround required running a separate Tor proxy, configuring Bitcoin Core to route through it, and hoping no clearnet connection leaked your broadcast. v31 makes that entire configuration a single flag in bitcoin.conf, which means the privacy floor for average node operators just went up considerably.
What Node Operators Need to Know
Running v31 when it reaches full release (expected in the second half of 2026) will require some attention to the new defaults. The cluster mempool is opt-in during the testnet phase but is expected to become the default in the production release. Node operators who have customized their bitcoin.conf with specific ancestor or descendant limit overrides will need to review those settings, because cluster mempool replaces the old limit framework entirely.
Memory usage patterns will shift. The old mempool tracked individual transaction relationships in a graph structure. Cluster mempool maintains sorted chunk lists within each cluster, which trades some memory overhead for faster query times when building block templates. For nodes running on constrained hardware (Raspberry Pi setups, for example), the testnet phase is the time to benchmark if the new structure fits within existing resource budgets.
The RPC interface also gets updates. Calls like getmempoolinfo and getrawmempool will return cluster-aware data, and mining pool software that integrates directly with Bitcoin Core's RPC will need to update their template-building logic to take advantage of the improved block construction. Pool operators who delay this update will not break anything, but they will leave fee revenue on the table compared to pools running v31-optimized template builders.
How v31 Compares to Previous Major Releases
Bitcoin Core major releases do not happen on a fixed schedule, and each one tends to focus on a different layer of the stack. For context on where v31 fits, here is how the last three major releases compare.
Release | Key Change | Impact Area |
v28 (2024) | Compact block relay improvements | Network propagation speed |
v29 (2025) | Miniscript expansion for descriptors | Wallet flexibility |
v30 (2025) | Package relay (limited) | Transaction package handling |
v31 (2026) | Cluster mempool + Tor-only broadcasting | Mempool architecture + privacy |
v31 is the largest single-release change to mempool logic since the introduction of Replace-by-Fee (RBF) in v0.12 back in 2016. The cluster mempool concept has been in development since 2023, with Bitcoin Core developer Pieter Wuille's original proposal outlining the theoretical framework that v31 now implements.
Frequently Asked Questions
What is cluster mempool in Bitcoin Core v31?
Cluster mempool is a redesign of how Bitcoin Core organizes unconfirmed transactions. Instead of tracking each transaction's individual ancestor and descendant relationships, v31 groups related transactions into clusters (up to 64 transactions or 101 kilobytes) and sorts them by fee rate within each cluster. This produces more accurate block templates for miners and better fee estimates for wallets.
When will Bitcoin Core v31 be officially released?
The v31.0rc4 release candidate hit testnet on April 11, 2026. Full production release is expected in the second half of 2026, though Bitcoin Core does not commit to fixed release dates. The rc4 designation means the code has been through multiple rounds of testing and review, which typically places the final release within a few months.
Does Tor-only broadcasting hide my Bitcoin transactions?
It does not hide the transactions, which remain publicly visible on the blockchain. What it hides is the link between your IP address and the transaction you broadcast. By forcing all outbound transaction relays through Tor or I2P, chain analysis firms cannot associate your network identity with your on-chain activity through relay timing analysis.
Will cluster mempool lower Bitcoin transaction fees?
It will not directly lower the base fee market, which is driven by block space demand. But it will improve fee estimation accuracy, meaning wallets will less frequently overpay for confirmation speed. Miners also benefit from better block construction, which means transactions that previously might have been overlooked due to complex ancestry now get properly prioritized by fee rate.
Bottom Line
Bitcoin Core v31 is the most significant infrastructure update to hit Bitcoin's transaction layer since Replace-by-Fee. Cluster mempool replaces a decade-old transaction management system with one that handles complex transaction packages more efficiently and gives miners genuinely better block templates. The Tor-only broadcasting option closes a privacy gap that chain analysis firms have relied on since Bitcoin's early years.
For most Bitcoin holders, the practical effects will show up as more accurate fee estimates and fewer stuck transactions, especially for CPFP and batched payment scenarios. For node operators, the second half of 2026 is when to start testing the new defaults. And for anyone sending transactions from a jurisdiction where financial privacy matters, the ability to broadcast exclusively through Tor without external tooling is worth the node upgrade alone. The testnet phase is live now, and the v31.0rc4 source code is available on GitHub for anyone who wants to run it before the production release.
This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency trading involves substantial risk. Always conduct your own research before making trading decisions.
