Cluster Mempool

Cluster mempool is a major reworking of how Bitcoin Core organises unconfirmed transactions. Instead of tracking loose ancestor and descendant relationships, it places every transaction that is connected through spending into a single group called a cluster, then sorts ("linearizes") each cluster into fee-rate-ordered chunks. This lets a node reason precisely about which transactions a rational miner would include first — a question the legacy mempool could only approximate.

What the old mempool got wrong

The legacy mempool tracked, for every transaction, its ancestor set and descendant set, and enforced limits on each. That worked, but it left the node unable to answer the question that actually matters: given everything waiting for confirmation, what is the true "mining score" of this transaction — the feerate at which it would realistically enter a block once its dependencies are accounted for? Ancestor feerate is only an approximation, and the gap between approximation and truth is exactly where pinning attacks and perverse eviction decisions live. A node could evict a transaction that miners would have wanted, or accept a replacement that actually made the next block worse.

Clusters, chunks, and feerate diagrams

Cluster mempool starts from a simple observation: transactions connected by spends must be evaluated together. Each connected component becomes a cluster with a bounded size, and each cluster is linearized into an ordering that a miner would follow, then cut into chunks of monotonically decreasing feerate. Plotting cumulative fees against cumulative size for those chunks yields a feerate diagram, and comparing two candidate mempool states becomes a comparison of two diagrams: if one diagram is at least as high everywhere, that state is strictly better for miners. The linearization research drew on maximum-ratio-closure and linear-programming techniques to find near-optimal orderings fast enough to run inside the P2P validation path. Bounding cluster size bounds how much work must be redone when a new transaction arrives, which is what makes the whole approach practical on a modest home node.

Why miners and node operators should care

For anyone building block templates — a mining pool, or a solo miner running their own node behind a Bitaxe — cluster mempool means the transactions your node holds are already sorted the way a template builder wants them, so block assembly gets simpler and more accurate. For everyone else, the payoff is Replace-by-Fee logic that is harder to game: a replacement is judged by whether it genuinely improves the feerate diagram, not by rules of thumb an attacker can straddle. That directly strengthens anti-pinning policy for Lightning and other time-sensitive protocols, and it makes fee estimation better grounded, because estimates can be read off the same diagram miners effectively optimise.

Relationship to TRUC and deployment status

Cluster mempool generalises the idea behind TRUC: where TRUC transactions bound topology only for transactions that opt in, cluster mempool bounds cluster size for all transactions, far less restrictively. The two are complementary — TRUC shipped first as a targeted fix, while cluster mempool rebuilds the foundation underneath. The project spans multiple Bitcoin Core releases and was staged toward release in the 31.x era; because this is a moving target, confirm the current status against the Bitcoin Core release notes for the version you actually run rather than trusting any snapshot in time. Either way, the design is settled enough to understand today: it is the engine that makes modern mempool policy robust, and a good example of Bitcoin's slow, verify-everything upgrade culture working as intended.

None of this demands anything from an operator beyond running current software, but it rewards those who do. A node with a cluster-aware mempool relays and holds a more honest picture of pending demand, which means the fee its wallet suggests, the template its miner builds, and the replacement it accepts or rejects all track what the network will actually do. That consistency across thousands of independently run nodes is the decentralized version of a matching engine: nobody coordinates it, yet everyone converges on compatible views of transaction priority. The years of review behind the change — design documents, formal write-ups of the linearization mathematics, staged merges — are also a useful calibration for evaluating other proposed changes to Bitcoin: this is what the bar looks like when the mempool itself is being rebuilt underneath live money.