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.

Policy Setting	Default Limit	Configuration Variable	Purpose
Max Ancestor Count	$25$ transactions	-limitancestorcount	Restricts how many parents an unconfirmed transaction can have.
Max Ancestor Size	$101,000$ vB (101 kvB)	-limitancestorsize	Restricts the cumulative size of a transaction's parent lineage.
Max Descendant Count	$25$ transactions	-limitdescendantcount	Restricts how many children can spend an unconfirmed output.
Max Descendant Size	$101,000$ vB (101 kvB)	-limitdescendantsize	Restricts the cumulative size of all child transactions.

---

💥 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: * It checks the ancestor count for $Tx_{25}$, which evaluates to $25$ unconfirmed ancestors. * Since $25 \ge \text{Limit } (25)$, adding $Tx_{25}$ would make the ancestor count $26$. * 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.