Cluster Mempool

What Is Cluster Mempool?

Cluster mempool is a fundamental redesign of how Bitcoin Core organizes and prioritizes unconfirmed transactions in the mempool. Instead of tracking each transaction's ancestors and descendants independently, cluster mempool groups all related transactions (those connected through parent-child spending relationships) into clusters: connected components in the transaction graph.

The redesign was developed primarily by Suhas Daftuar and Pieter Wuille at Chaincode Labs over multiple years. It addresses a core tension in the legacy mempool: the system used one ordering method (ancestor feerate) for mining and a contradictory one (descendant feerate) for eviction. These two orderings could produce conflicting decisions, sometimes evicting the very transactions that would be most profitable to mine.

By unifying all mempool operations under a single consistent ordering derived from cluster linearization, cluster mempool produces better block templates, more accurate fee estimation, and stronger resistance to transaction pinning attacks.

How It Works

Cluster mempool introduces three core concepts: clusters, linearizations, and chunks. Together, they provide a unified framework for reasoning about which transactions belong in the next block and which should be evicted when the mempool is full.

Clusters

A cluster is a connected component in the mempool's transaction graph. If transaction B spends an output of transaction A, they belong to the same cluster. If transaction C spends an output of B, all three form a single cluster. Any two transactions that can be connected through a chain of parent-child relationships are grouped together.

Bitcoin Core 31.0 enforces cluster size limits: a maximum of 64 transactions and 101,000 virtual bytes per cluster. These limits replace the legacy per-transaction caps of 25 ancestors and 25 descendants, which were insufficient because a fully connected component could still grow arbitrarily large despite individual caps.

Linearization

Linearization is the process of producing a topologically valid ordering of transactions within a cluster, optimized so the highest-feerate subsets appear first. A topologically valid ordering means all parent transactions appear before their children (since a child cannot be mined without its parents).

Finding a truly optimal linearization is computationally expensive: O(n × 2^(n/2)) in the worst case. Bitcoin Core uses practical polynomial-time algorithms instead:

• LIMO: an O(n²) algorithm that takes an existing linearization and improves it using heuristic high-feerate subset finding
• Merge: an O(n²) algorithm that combines two linearizations to produce one at least as good as both inputs
• Spanning-Forest Linearization (SFL): a newer algorithm developed by Pieter Wuille for more practical real-world performance

Because clusters are capped at 64 transactions, re-linearization only needs to run on the affected cluster when a new transaction arrives, not the entire mempool.

Chunks

Once a cluster is linearized, it is divided into chunks: groups of consecutive transactions in the ordering that would be mined together. The chunking algorithm runs in O(n) time: iterate through the linearized transactions and merge consecutive chunks whenever a later chunk has a higher feerate than the preceding one. Within a cluster, chunk feerates are monotonically decreasing.

This chunking produces a feerate diagram: a plot of cumulative transaction size (x-axis, in vbytes) against cumulative fees (y-axis). The feerate diagram is the key data structure for comparing mempool states. A replacement transaction is accepted only if the resulting mempool's feerate diagram is strictly better than the current one.

Unified Ordering

With clusters linearized and chunked, all mempool operations use the same ordering:

• Mining (block template construction): select chunks in descending feerate order until the block is full
• Eviction: remove chunks in ascending feerate order when the mempool exceeds capacity
• RBF evaluation: compare feerate diagrams before and after replacement to determine if the new transaction set is strictly better

Mining and eviction become exact mirrors. The first chunk evicted is guaranteed to be the last chunk that would be mined, eliminating the contradictions of the legacy system.

What It Replaces

The legacy mempool maintained two separate ordering systems that frequently contradicted each other:

• Ancestor feerate for mining: calculated each transaction's effective feerate by including all its unconfirmed ancestors, then selected the highest-scoring transactions for block templates
• Descendant feerate for eviction: calculated each transaction's effective feerate by including all its descendants, then removed the lowest-scoring transactions when the mempool was full

These orderings could produce absurd results. The transaction with the lowest descendant feerate (first to be evicted) might simultaneously have a high ancestor feerate (one of the best to mine). The legacy system could evict the most profitable transaction in the mempool.

The old ancestor and descendant limits (25 each) also created practical problems. They forced artificial constraints on transaction chains and enabled pinning attacks where an adversary could attach low-feerate descendants to a victim's transaction, making RBF replacement expensive or impossible.

Use Cases

Better Block Templates for Miners

Miners benefit directly from cluster mempool because block templates now reflect a globally optimal fee ordering. The legacy ancestor-feerate heuristic could miss profitable transaction combinations, leaving fees on the table. Cluster mempool's chunk-based selection captures the full value of complex transaction dependency chains.

Improved Fee Estimation

Fee estimation becomes more accurate when the mempool has a single, consistent ordering. Applications and wallets can better predict what feerate a transaction needs to be included in the next block. Bitcoin Core 31.0 also lowered the minimum fee rate bucket from 1 sat/vB to 0.1 sat/vB, matching the default minimum relay fee. For more on how fees interact with block space demand, see the Bitcoin fee market dynamics research article.

Lightning Network and Layer 2 Protocols

Protocols that depend on predictable mempool behavior, such as Lightning channels and other Layer 2 systems, benefit from the more rational transaction ordering. Force-close transactions and their fee bumps are organized within cluster boundaries, making their interactions more predictable.

One significant change for Lightning: the CPFP carve-out (which allowed a single additional child transaction to exceed package limits) was incompatible with cluster mempool and has been removed. It is replaced by TRUC (Topologically Restricted Until Confirmation) transactions, defined in BIP 431. TRUC transactions use nVersion=3 and enforce a strict one-parent, one-child topology with "sibling eviction" that replicates carve-out functionality more cleanly.

Transaction Pinning Resistance

Transaction pinning is an attack where an adversary manipulates mempool policy to prevent a victim's transaction from confirming or being replaced. The legacy mempool's complex rules (no-new-parents requirement for RBF, ancestor/descendant limits) created multiple pinning vectors.

Cluster mempool's feerate-diagram-based RBF evaluation eliminates many of these vectors. A replacement is accepted if it makes the mempool strictly better as measured by the diagram, regardless of whether it introduces new unconfirmed parents or changes the cluster topology.

Inspecting Clusters

Bitcoin Core 31.0 introduced new RPC commands for inspecting cluster mempool state:

# View all transactions in the same cluster, their
# ordering, and chunk grouping
bitcoin-cli getmempoolcluster <txid>

# Retrieve the entire mempool's feerate diagram
bitcoin-cli getmempoolfeeratediagram

# Inspect a single transaction's chunk info
# (now includes chunk size and chunk fees)
bitcoin-cli getmempoolentry <txid>

These commands allow node operators, miners, and developers to understand how transactions are being grouped and prioritized. The feerate diagram endpoint is particularly useful for evaluating whether a proposed replacement would be accepted.

Risks and Considerations

Cluster Size Limits May Reject Valid Transactions

The 64-transaction, 101 kB cluster limit means that adding a new transaction which would merge two large clusters (or push an existing cluster over the limit) will be rejected. Applications that create long chains of unconfirmed transactions need to be aware of these constraints. The limits are configurable via Bitcoin Core's debug command-line arguments, but the defaults are what the network broadly enforces for relay.

CPFP Carve-Out Removal

The removal of CPFP carve-out is a breaking change for Lightning implementations that relied on it. Node software must migrate to TRUC (v3) transactions to maintain the ability for both channel parties to fee-bump commitment transactions. Lightning implementations including LND and Core Lightning have been updating to support this transition.

Linearization Quality

Because optimal linearization is computationally infeasible for larger clusters, the practical algorithms used are heuristic approximations. In rare cases, the linearization might not capture the true optimal ordering, meaning a slightly suboptimal set of transactions could be selected for mining. The 64-transaction cluster cap keeps this error small in practice.

Transition Period

Nodes running older Bitcoin Core versions still use the legacy mempool, meaning the network will have mixed behavior during the upgrade period. Transactions that are valid under cluster mempool rules might be rejected by legacy nodes, and vice versa. As adoption of Bitcoin Core 31.0+ spreads, this divergence will diminish.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.