Ancestor and Descendant Limits

Ancestor and descendant limits are mempool-policy caps on how many unconfirmed transactions may be linked together in a chain of spends. An "ancestor" set is every unconfirmed parent a transaction depends on; a "descendant" set is every unconfirmed child that builds on it. By default, Bitcoin Core long capped each set at 25 transactions and 101 kvB of virtual size, rejecting anything that would exceed these with the error too-long-mempool-chain. Anyone who has tried to daisy-chain spends from an unconfirmed change output has eventually hit this wall.

Why the limits exist

Every time a transaction enters or leaves the mempool, a node must recompute the aggregate fees and sizes of all connected transactions to keep mining priority and eviction decisions correct. A transaction's true value to a miner is not its own feerate but the package feerate of everything that must confirm with it — a low-fee parent with a high-fee child is worth mining as a unit. Computing these package relationships is quadratic-flavored work: without a bound, an adversary could build enormous chains that force expensive recalculation on every node with every update, a classic denial-of-service vector. The limits cap this worst-case work at something every Raspberry Pi node can handle, which is a decentralization decision as much as an engineering one: policy that only datacenter nodes could afford would push the network toward fewer, bigger validators.

Fee-bumping and the pinning problem

The limits also feed directly into fee-bumping economics. Child-pays-for-parent (CPFP) works by attaching a high-fee child to a stuck parent so miners scoop up both; replace-by-fee instead rewrites the original. But a descendant chain that is already at the limit leaves no room to attach a new child — which is precisely what a pinning attack exploits. An adversary broadcasts junk descendants to fill a victim's quota, blocking the honest fee bump. This matters intensely for Lightning, where a channel's security depends on confirming a justice or commitment transaction before a timeout. Mechanisms like the CPFP carve-out and anchor outputs were engineered specifically to reserve fee-bumping room inside these limits.

The move to cluster mempool

Bitcoin Core 31.0 replaced separate ancestor/descendant enforcement with a unified "cluster" model. Instead of bounding chains in each direction, it limits any connected component of related transactions to 64 transactions and 101 kvB, simplifying the accounting and improving block-template construction: the mempool can now always linearize clusters into the optimal mining order. The practical intuition is unchanged — unconfirmed spend chains have a hard ceiling — but the bookkeeping is cleaner and harder to game.

What this means in practice

For everyday wallet use, the limits argue for a few simple habits. Avoid building long chains of spends from unconfirmed change — wait for a confirmation, or consolidate outputs during low-fee periods so future spends draw on confirmed coins. If you operate a service that pays from hot wallets, batch payouts rather than daisy-chaining them, and leave headroom in any package you expect to fee-bump later. Wallets that surface unconfirmed-ancestor counts make these constraints visible; those that hide them produce the mysterious "transaction rejected" moments this entry exists to explain.

For a miner or node runner, these limits explain several everyday puzzles: why a long chain of unconfirmed self-transfers suddenly bounces, why an exchange batching withdrawals from unconfirmed outputs stalls, and why wallet developers preach confirming before re-spending. For anyone building on Bitcoin, they are the boundary conditions of fee management. The limits are policy, not consensus — a miner can mine a longer chain if it arrives in a block — but since nodes will not relay violations, policy is what shapes real-world propagation. See mempool policy for the broader rule set these limits belong to, and anchor outputs for how second-layer protocols reserve room within them.