Understanding Mempool Ancestors & Descendants: Consensus Limits and DAG Structures

In the Bitcoin mempool, transactions are not isolated. Because an unconfirmed transaction can spend outputs created by other unconfirmed transactions, they form a complex dependency structure known mathematically as a Directed Acyclic Graph (DAG).

To navigate and secure this graph, nodes must categorize relationships into Ancestors (predecessors) and Descendants (successors) and enforce strict limits on their depth and volume.

1. Ancestors vs. Descendants: Mathematical Definition

Let's define two unconfirmed transactions, $T_1$ and $T_2$, sitting inside a node's local mempool:

$$\begin{aligned} \text{If } T_2 \text{ spends an outpoint created by } T_1: \ T_1 &\in \text{Ancestors}(T_2) \ T_2 &\in \text{Descendants}(T_1) \end{aligned}$$

 THE DEPENDENCY PIPELINE

 ┌─────────────────────┐
 │ Transaction T1 │ ◄── Parent (Ancestor of T2 & T3)
 └──────────┬──────────┘
 │ (spends outpoint)
 ▼
 ┌─────────────────────┐
 │ Transaction T2 │ ◄── Child (Descendant of T1)
 └──────────┬──────────┘
 │ (spends outpoint)
 ▼
 ┌─────────────────────┐
 │ Transaction T3 │ ◄── Grandchild (Descendant of T1 & T2)
 └─────────────────────┘

• Ancestors: All transactions whose outputs are directly or indirectly spent by a given transaction, recursively traversing up the dependency chain. A transaction cannot be mined until all of its ancestors are mined first.

• Descendants: All transactions that directly or indirectly spend any output created by a given transaction, recursively traversing down the dependency chain. If a transaction is evicted, all of its descendants must be evicted simultaneously.

️ 2. Why Limits Exist: Defensive Relay Engineering

Without limit rules, a malicious user could flood a node with a massive, interlocking dependency web containing thousands of transactions. When a new block arrives or a transaction is replaced, the node would have to recursively evaluate the entire web, triggering a Denial of Service (DoS) event via CPU lockup.

Algorithmic Complexity Attacks

If a node has to evaluate a chain of length $N$, a naive sorting algorithm could run in $O(N^2)$ quadratic complexity. By capping $N$ at a small number, Bitcoin Core guarantees that mempool re-sorting runs in microsecond timescales, preventing CPU exhaustion.

3. The Core Limits (policy.h)

Bitcoin Core enforces standard limits on both ancestor and descendant sets. If a newly submitted transaction violates any of these, it is rejected with the RPC error too-long-mempool-chain.

4. Reaching the Limit: A Step-by-Step Scenario

Consider an exchange that is batching withdrawals.

1. The exchange broadcasts a transaction $Tx_0$ which creates a change output.

2. Before $Tx_0$ confirms, the exchange creates $Tx_1$ spending that change output.

3. This continues sequentially until $Tx_{24}$ is broadcast, creating a chain of unconfirmed dependencies of depth $25$.

4. If the exchange attempts to broadcast $Tx_{25}$ (the 26th transaction in the unconfirmed chain), the node's validation engine stops:

5. It checks the ancestor count for $Tx_{25}$, which evaluates to $25$ unconfirmed ancestors.
6. Since $25 \ge \text{Limit } (25)$, adding $Tx_{25}$ would make the ancestor count $26$.
7. The node rejects the transaction and throws: json { "code": -26, "message": "too-long-mempool-chain, would exceed ancestor limit" }

Impact on Wallets

For highly active wallets or applications doing automated payouts, these limits require developers to implement careful UTXO management strategies. If a wallet relies on a single unconfirmed change UTXO to fund sequential transactions, it will quickly lock itself out after 25 transactions until the next block confirms and resets the unconfirmed ancestor graph.