Cluster Mempool partitions the mempool into connected components of parents and children, builds a topologically valid linearization for each, and uses it consistently for mining, eviction, relay, and replacement policy.
A cluster is a connected component in the graph of unconfirmed transactions linked by parent–child relationships. Independent clusters can be evaluated separately, so a change in one does not require recalculating the rest of the mempool. [2]
For every cluster, the node constructs a topologically valid linearization and divides it into chunks whose feerates descend from the most attractive. It selects the best chunks from the front for a block and evicts the least attractive from the back. [2]
The former ancestor and descendant limits, together with different approximations for mining and eviction, could not always express the real value of a complex package. A bounded cluster allows the node to search for a better ordering with predictably bounded work. [5]
This is local mempool and mining policy, not a new consensus rule. Nodes may receive different transactions, run another version or configuration, and hold different mempools; the validity of a transaction confirmed in a block is unchanged. [2]
Bitcoin Core 31.0 replaced the old mempool implementation with Cluster Mempool. It also added the getmempoolcluster and getmempoolfeeratediagram RPCs for inspecting a cluster, its linearization, and its feerate diagram. [1]
The default policy limits one cluster to 64 transactions and 101 kB of virtual size. Node arguments can change the limits, but acceptance or relay by your node does not guarantee the same policy among peers and miners. [1]
The model aligns mining selection, eviction, transaction announcements, and RBF. A replacement must produce a feerate diagram that is at least as good at every point and strictly better somewhere, while also satisfying the other replacement rules; the old CPFP carve-out was removed in favor of TRUC and sibling eviction. [3]
Before making a claim about a particular transaction, verify the node version and configuration, the complete cluster and its chunks, the feerate diagram, and the remaining RBF conditions. A wallet must not assume that the whole network uses the same local policy. [4]
For the clearest picture, read this entry together with Mempool, Package Relay, CPFP (Child Pays for Parent), Replace-by-Fee (RBF), Transaction Fees, Block Template.
01Is Cluster Mempool a consensus change?+
No. Bitcoin Core 31.0 changed its local mempool, mining selection, and relay policy; consensus validity of transactions in a block remained unchanged.
02What changed for fee bumping?+
The node evaluates dependent transactions in chunks and, for RBF, requires a strictly better feerate diagram together with the other replacement conditions. The outcome still depends on the policy of the particular node.