Cluster Mempool Lands in Bitcoin Core: “Problems Are Easier in Chunks”
November 25 2025 – Bitcoin Core v30.0 merges a major redesign of the transaction pool that groups related transactions into “clusters” and orders them in small “chunks.” The change, championed by Suhas Daftuar and Pieter Wuille, promises tighter alignment between mem‑pool behavior and miner incentives, while simplifying fee‑bumping and second‑layer security.
Why the mempool matters
The mempool is the holding area for every unconfirmed transaction a node sees. It underpins three core functions:
- Fee estimation – users rely on mempool data to gauge how much they need to pay for timely confirmation.
- Replacement (RBF) handling – a sender may issue a higher‑fee replacement transaction to accelerate inclusion.
- Block template construction – miners pull transactions from the mempool to fill the next block.
In Bitcoin Core up to version 30.0 the mempool was organised around two overlapping metrics:
- Ancestor feerate – the average fee‑rate of a transaction together with all its required parents.
- Descendant feerate – the average fee‑rate of a transaction together with all its children that depend on it.
These two rankings drive opposite decisions: miners look forward (ancestor feerate) when selecting transactions, while nodes evict when full by looking backward (descendant feerate). The mismatch can cause eviction of high‑value ancestors, unpredictable fee‑bumping, and edge‑case attacks against second‑layer protocols that need reliable on‑chain enforcement.
The “Cluster Mempool” concept
The new design treats a set of mutually dependent transactions as a cluster—a sub‑graph of the overall mempool in which each transaction spends outputs created by another member of the same set. Rather than trying to globally reorder millions of individual transactions, the code now:
-
Divides each cluster into “chunks.”
A chunk is a small, directionally consistent bundle (e.g., two or three transactions) that can be sorted independently. -
Ranks chunks by feerate per byte.
Within a cluster, chunks are ordered from highest to lowest fee‑rate, respecting parent‑child dependencies. -
Builds block templates from the top‑ranked chunks across all clusters.
Miners iterate over clusters, pulling the best chunk from each until the block is full. -
Evicts low‑ranked chunks when the mempool exceeds its limit.
Nodes discard the cheapest chunks first, guaranteeing that evicted transactions are those least likely to be included by any miner. - Simplifies replacement logic.
A replacement transaction only needs to out‑fee the chunk(s) it would supplant, removing the complex ancestor/descendant calculations that previously made RBF outcomes uncertain.
The proposal caps clusters at 64 transactions and 101 kVB to keep the pre‑sorting cost tractable for everyday nodes.
Anticipated benefits
| Area | Current issue | How clusters & chunks help |
|---|---|---|
| Mining decentralisation | Miners may see divergent transaction sets due to inconsistent eviction rules. | A uniform chunk‑ranking ensures every miner evaluates the same profitability spectrum, widening the pool of viable block templates. |
| User fee‑estimation | Fee estimators can be skewed when ancestor and descendant feerates diverge. | A single, monotonic ranking eliminates “hidden” low‑feerate ancestors, making estimations more reliable. |
| Second‑layer security | Protocols that post on‑chain commitments (e.g., roll‑up finality transactions) risk eviction of required ancestors. | Predictable eviction and replacement behaviour reduces the chance that a crucial anchor transaction disappears before a child can be confirmed. |
| RBF predictability | Replacement may fail if the transaction sits in an unfavorable part of the graph. | A replacement only needs to beat the feerate of the chunk it replaces, a straightforward and transparent rule. |
Analyst view
The cluster‑based approach is a pragmatic compromise between the ideal of a globally sorted mempool and the reality of limited node resources. By limiting the size of clusters, the algorithm keeps the computational overhead within a few milliseconds per incoming transaction—well within the performance envelope of a typical full node.
Critics may point out that the 64‑transaction cap could force large, legitimate transaction chains (e.g., multi‑hop Lightning Network closures) into separate clusters, potentially re‑introducing fragmentation. However, developers argue that in practice most on‑chain activity stays well below this threshold, and the cap is adjustable via a soft‑fork if usage patterns evolve.
Early testing on testnet shows a measurable reduction in mempool churn and more consistent fee‑rate curves across nodes. If mainnet adoption mirrors these results, the change could smooth fee‑estimation for end‑users and provide a sturdier foundation for the growing ecosystem of layer‑2 solutions.
Key takeaways
- Cluster mempool landed in Bitcoin Core 30.0 (PR #33629). It reorganises pending transactions into related groups (clusters) and processes them in small, fee‑rate‑ordered bundles (chunks).
- Single‑ranking system eliminates the ancestor/descendant clash that previously led to unpredictable eviction and fee‑bumping outcomes.
- Mining, fee estimation, and second‑layer protocols stand to gain from a mempool that mirrors miner incentives more closely.
- Performance‑friendly limits (64 txs / 101 kVB per cluster) keep the additional bookkeeping affordable for all nodes.
- The design is still young; monitoring on mainnet will be essential to confirm that the theoretical gains translate into real‑world stability.
Developers and researchers interested in a deeper dive can consult the original design discussion on Delving Bitcoin (overview [393] and feerate diagrams [553]) and the GitHub pull request that merged the code.
Prepared for Bitcoin Magazine’s “The Core Issue” newsletter.
Source: https://bitcoinmagazine.com/print/the-core-issue-cluster-mempool-problems-are-easier-in-chunks
