bitcoin-core mempool mining lightning-network

Understanding Bitcoin's Cluster Mempool: The Biggest Change to Transaction Selection in Years

Bitcoin Index · · 7 min read
Understanding Bitcoin's Cluster Mempool: The Biggest Change to Transaction Selection in Years

Bitcoin Core 31.0 RC1 just shipped with cluster mempool, and you’d be forgiven for missing it in the release notes. No flashy UX changes. No consensus rules altered. Just a fundamental redesign of how Bitcoin nodes organize, select, and evict unconfirmed transactions.

This is a big deal. After a decade of using the same ancestor/descendant framework, Bitcoin Core now aligns its mempool with actual mining incentives. The result: better block templates, more reliable fee estimation, and stronger security guarantees for Lightning Network and other Layer 2 protocols.

Here’s what changed, why it matters, and what you need to know.

The problem: misaligned incentives

Bitcoin’s mempool has long juggled two different perspectives on unconfirmed transactions:

Ancestor feerate looks backward at a transaction and all its unconfirmed parents. This was used for building block templates.

Descendant feerate looks forward at a transaction and all its unconfirmed children. This was used for deciding what to evict when the mempool fills up.

These two rankings are not opposites. They’re both approximations, and they contradict each other in ways that create real problems:

  • Miners get suboptimal blocks. The ancestor feerate heuristic doesn’t always find the most profitable transaction set, especially in complex transaction graphs.
  • The mempool can evict the wrong things. When full, it might kick out the transaction that would have been most valuable to miners.
  • RBF (Replace-By-Fee) becomes unpredictable. Whether a replacement gets accepted depends on graph shape in non-obvious ways.
  • Lightning security breaks down. Malicious actors can exploit these inconsistencies to pin penalty transactions or evict necessary ancestors.

This isn’t hypothetical. Bitcoin Core issue #27677 documented how these misalignments created real attack vectors for Lightning and other Layer 2 protocols.

The old system worked well enough for simple transaction patterns, but it was fundamentally a patchwork. Cluster mempool fixes this by using a single, unified view of transaction value.

The solution: clusters and chunks

Cluster mempool introduces two key concepts:

A cluster is a group of related unconfirmed transactions. If transaction B spends an output from transaction A, they’re in the same cluster. If C spends from B, all three are clustered together.

A chunk is a subset of transactions from a cluster, sorted by feerate from highest to lowest while respecting dependency order (parents before children).

Here’s an example cluster with 10 transactions, sorted into chunks:

[A,D] → 50 sat/vB
[B,E] → 30 sat/vB
[C,F] → 20 sat/vB
[G,J] → 10 sat/vB
[I,H] → 5 sat/vB

The key insight: optimal chunks never cross cluster boundaries. If you limit cluster size, you limit how much computation is needed when new transactions arrive. Bitcoin Core can pre-sort all clusters, then use chunk feerates as a universal “transaction selection score” across every mempool operation.

This gives you three wins:

1. Block template construction: Grab the highest-feerate chunks from all clusters until the block is full. This produces nearly optimal blocks.

2. Mempool eviction: When the mempool fills up, remove the lowest-feerate chunks. No more accidentally evicting high-value transactions.

3. Replace-By-Fee (RBF): Compare the feerate diagram before and after the replacement. If it strictly improves, accept it. Much simpler and more predictable than the old BIP 125 rules.

These three operations now use the same ranking system. That’s the breakthrough.

Technical details: how it works

Cluster limits

Cluster mempool replaces the old 25-transaction ancestor/descendant limits with new cluster limits:

  • 64 transactions per cluster
  • 101 kvB (kilovirtual bytes) total size per cluster

Why these numbers? Computational cost. The linearization algorithm that sorts clusters into chunks scales with cluster size. Smaller clusters mean faster recomputation.

Most users won’t hit these limits. The main impact is on services that create long chains of unconfirmed transactions without batching, which was already poor practice.

Linearization: sorting clusters into chunks

Cluster mempool uses an algorithm called spanning-forest linearization (SFL) to find the optimal chunk ordering.

The goal: arrange transactions to maximize fee collection while respecting dependencies (parents must come before children). This is represented as a directed acyclic graph (DAG), and SFL searches for high-feerate subsets that can be included together.

The algorithm includes a cost model to control CPU time. If a cluster can’t be perfectly linearized within the time budget, it produces a “good enough” approximation.

Feerate diagrams: the new RBF logic

A feerate diagram is a mathematical representation of cumulative fees available at each feerate threshold.

When evaluating a replacement transaction, Bitcoin Core now:

  1. Generates a feerate diagram of the current mempool
  2. Generates a diagram after the replacement
  3. Checks if the new diagram is strictly better (higher fees at all block sizes)

If yes, the replacement is accepted. If no, it’s rejected because it would make some future block less profitable.

This replaces the old BIP 125 heuristics, which could be gamed. Feerate diagrams are incentive-compatible: miners benefit from every accepted replacement.

What changed: policy rules

RBF updates

Removed:

  • BIP 125 signaling requirement (PR #30592)
  • Restriction on introducing new inputs

New/updated:

  • Replacement must pay absolute fee ≥ sum of original transactions
  • Additional fees must cover bandwidth at incremental relay feerate (default: 0.1 sat/vB, as of PR #33106)
  • Feerate diagram must strictly improve (core cluster mempool rule)
  • Cannot conflict with more than 100 distinct clusters (CPU protection)

CPFP carveout: removed

The CPFP (Child-Pays-For-Parent) carveout rule no longer exists in cluster mempool.

This was a special exception that allowed one extra transaction beyond ancestor limits. It was a workaround for the old ancestor/descendant conflicts. With unified cluster limits, it’s no longer needed or meaningful.

Impact: Lightning implementations that relied on CPFP carveout need to migrate to v3 transaction relay (TRUC) or other pinning-resistant mechanisms.

Who benefits and how

For miners

Better block templates, plain and simple. Cluster mempool produces near-optimal transaction selection without expensive recomputation.

Bitcoin Core developer Abubakar Sadiq Ismail tested cluster mempool against historical data and found it produced significantly better blocks than the old ancestor-based system.

More fee revenue. One unified algorithm. No graph shape quirks leaving money on the table.

For node operators

Better performance. Pre-sorted clusters make eviction and block building faster.

No action required. Upgrade to Bitcoin Core 31.0 and cluster mempool just works.

Caveat: Services creating very long unconfirmed transaction chains (>64 tx) will need to adjust their batching strategy.

For users

More accurate fee estimation. The mempool state now reflects what miners actually include, not an approximation.

More predictable RBF. Replacement logic is deterministic based on feerate diagrams.

Faster propagation. Transaction relay now uses chunk feerate comparisons to prioritize announcements.

For Lightning Network and Layer 2

Security improvements. It’s harder to pin or evict penalty/justice transactions.

Predictable behavior. RBF logic aligns with mining incentives, reducing uncertainty about whether on-chain enforcement will work.

Better enforcement guarantees. On-chain enforcement transactions have clearer propagation paths.

Migration path

For regular users

Nothing. When you upgrade to Bitcoin Core 31.0, cluster mempool is automatically enabled.

For developers and services

Ask yourself:

  • Do you create long chains of unconfirmed transactions (>25 tx)?
  • Do you rely on CPFP carveout for pinning resistance?
  • Do you parse ancestor/descendant RPC fields?

If yes:

  1. Long chains: Implement better batching to stay under 64 tx/cluster
  2. CPFP carveout: Migrate to v3 transaction relay
  3. RPC fields: Ancestor/descendant info is still available (calculated on-demand), but the internal mempool no longer caches it

For lightning implementations

Lightning node software that used CPFP carveout for anchor outputs needs to move to ephemeral anchors using v3 (TRUC) transaction relay. Discussion is ongoing about optimal anchor output script constructions.

Timeline

This has been years in the making:

  • 2023: Initial cluster mempool proposal and discussions
  • 2024: Linearization algorithms developed and benchmarked
  • 2025, Nov 25: Cluster mempool merged into Bitcoin Core (PR #33629)
  • 2026, early: Bitcoin Core 31.0 RC1 released with cluster mempool
  • 2026, H2: Bitcoin Core 31.0 final release (expected)

Lead developers: Suhas Daftuar and Pieter Wuille.

Why this matters

Cluster mempool isn’t flashy. It doesn’t enable new features or change how you use Bitcoin.

What it does: align Bitcoin Core’s mempool with the economic reality of mining. That makes the network more predictable, more secure, and more efficient.

For miners, that means better revenue. For users, it means better fee estimation. For Lightning and Layer 2, it means stronger security guarantees.

And for Bitcoin as a whole, it means a more robust foundation for whatever comes next. By making optimal block templates accessible to all miners (not just those with custom mempool logic), cluster mempool helps preserve mining decentralization.

This is the kind of unglamorous, foundational work that makes Bitcoin better for the next decade. It deserves more attention than it’s getting.

Sources