<p>The ancestors of a mempool transaction <code>T</code> are unconfirmed transactions that this transaction <code>T</code> depends on in order to be included in the block chain (i.e. that are referenced by its inputs).</p>
<p>The descendants of a mempool transaction <code>T</code> are (necessarily unconfirmed) transactions that depend on this transaction <code>T</code> in order to be included in the block chain (i.e. that spend one or more of its outputs).</p>
<p>In both cases there can be multiple &quot;generations&quot; of descendants/ancestors (e.g. descendants of descendants):</p>
<pre><code>         Tb
        /
Ta  ---
        \        Td
          Tc ---/
                 \--- Te
                  \___ Tf

</code></pre>
<p><em>(Here, <code>Ta</code> and <code>Tc</code> are ancestors of <code>Te</code> but <code>Tb</code> and <code>Tf</code> are not ancestors of <code>Te</code>. <code>Td</code> is a descendant of <code>Tc</code> but <code>Tb</code> is not.)</em></p>
<p>As you may picture from the above outstanding piece of art, their management can quickly start to be tedious hence resource intensive.<br />
This resource usage (mostly RAM for storage and CPU to update them) impacts <strong>every single node</strong> not running with <code>-blocksonly</code> on the network, it is thus a DOS vector that must be limited. But how?</p>
<p>I can point you to the <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining" rel="nofollow noreferrer">bitcoin-core dev wiki</a> which reports the word of <a href="https://github.com/sdaftuar" rel="nofollow noreferrer">Suhas Daftuar</a> -one of the main architects of the system that is currently in place- regarding the trade-offs of different approaches to usage limitation, but as a TL;DR:<br />
The mempool needs to be in phase with miner incentives (don't drop the highest-paying transactions), while limiting its footprint on network nodes. Therefore, two limits are in place for the two &quot;views&quot; relative to a transaction:</p>
<ul>
<li>The size limit, accounted for in virtual bytes, of both its descendants and ancestors.</li>
<li>The count limit, accounted for in number of transactions, of both its descendants and ancestors.</li>
</ul>

CC BY-SA 4.0
2020-10-06T16:54:06.883Z
Thanks for your explanation and nice image. I understand now. One thing to note that I was originally confused about... when I would attempt to broadcast a transaction (txidA) that had 24 unconfirmed ancestors, I would get the error "too many descendants for tx <txidB> [limit: 25]". This confused me, but now I realize it's saying that the oldest ancestor of my new transaction (<txidB>) would now have too many descendants if I added my new transaction <txidA>. Its also true that txidA would have too many ancestors, but the code just happens to trigger first when checking txidB.
deezy
CC BY-SA 4.0
2020-10-13T19:05:32.837Z
I love the graphic! You could get even more use out of the graphic by adding an example, e.g. "Ta and Tc are ancestors of Te, but Tb and Tf are not ancestors of Te".
Murch
CC BY-SA 4.0
2021-05-07T17:20:58.383Z
+1 to murch's suggestion.
If i understand correctly: 
- Ta has 0 ancestors, and has descendants Tb, Tc, Td, Te, and Tf ................

- The only ancestor for Tc is Ta, and Tc has descendants Td, Te, and Tf ..............

- The ancestors for Te are Tc and Ta and has Te no descendants ................
sound right?
deezy
CC BY-SA 4.0
2021-05-07T17:23:47.617Z
Oops, overlooked it. Will address soon :)
Antoine Poinsot
CC BY-SA 4.0
2021-05-09T12:40:23.923Z
@ deezy this is right. I added @Murch's suggestion to comment the graphic.
Antoine Poinsot
CC BY-SA 4.0
2023-12-04T11:53:39.660Z
@deezy would you mind marking this answer as accepted if it answered your question?
Antoine Poinsot
CC BY-SA 4.0
2020-09-30T21:41:54.270Z
2023-12-04T11:52:49.677Z
2023-12-04T11:52:49.677Z
Antoine Poinsot
<p>In practice I've seen two instances of the <code>too-long-mempool-chain</code> error when trying to send a transaction:</p>
<p>When there are too many unconfirmed transactions chained together:</p>
<pre><code>&quot;too many descendants for tx &lt;txid&gt; [limit: 25]&quot;
</code></pre>
<p>When the chain of unconfirmed transactions is too big in size:</p>
<pre><code>&quot;exceeds descendant size limit for tx &lt;txid&gt; [limit: 101000]&quot;
</code></pre>
<p><a href="https://github.com/bitcoin/bitcoin/blob/25839661305ec9fe8c25d171e31270d95311a4e4/src/txmempool.cpp#L195" rel="noreferrer">In the code</a> I also see two more error cases that look similar, but I can't grasp what the difference is in these:</p>
<pre><code>&quot;exceeds ancestor size limit [limit: %u]&quot;
</code></pre>
<p>and</p>
<pre><code>&quot;too many unconfirmed ancestors [limit: %u]&quot;
</code></pre>
<p>The names &quot;ancestor&quot; and &quot;descendant&quot; seem backwards given that we use the reverse terminology in something like &quot;child pays for parent&quot;. Am I thinking about this correctly? Also, when would the latter 2 error messages get triggered?</p>

<json-rpc><mempool><sending><error>
Clarifying descendants/ancestors in error cases for too-long-mempool-chain
deezy
# Clarifying descendants/ancestors in error cases for too-long-mempool-chain

(Asked by: username_0 on 2020-09-23)

In practice I've seen two instances of the `too-long-mempool-chain` error when trying to send a transaction:

When there are too many unconfirmed transactions chained together:

```
"too many descendants for tx <txid> [limit: 25]"

```

When the chain of unconfirmed transactions is too big in size:

```
"exceeds descendant size limit for tx <txid> [limit: 101000]"

```

[In the code](https://github.com/bitcoin/bitcoin/blob/25839661305ec9fe8c25d171e31270d95311a4e4/src/txmempool.cpp#L195) I also see two more error cases that look similar, but I can't grasp what the difference is in these:

```
"exceeds ancestor size limit [limit: %u]"

```

and

```
"too many unconfirmed ancestors [limit: %u]"

```

The names "ancestor" and "descendant" seem backwards given that we use the reverse terminology in something like "child pays for parent". Am I thinking about this correctly? Also, when would the latter 2 error messages get triggered?

**Tags:** json-rpc, mempool, sending, error


---

## 1 answers

### Answer by username_1 on 2020-09-30. Score: 5

The ancestors of a mempool transaction `T` are unconfirmed transactions that this transaction `T` depends on in order to be included in the block chain (i.e. that are referenced by its inputs).

The descendants of a mempool transaction `T` are (necessarily unconfirmed) transactions that depend on this transaction `T` in order to be included in the block chain (i.e. that spend one or more of its outputs).

In both cases there can be multiple "generations" of descendants/ancestors (e.g. descendants of descendants):

```
         Tb
        /
Ta  ---
        \        Td
          Tc ---/
                 \--- Te
                  \___ Tf

```

*(Here, `Ta` and `Tc` are ancestors of `Te` but `Tb` and `Tf` are not ancestors of `Te`. `Td` is a descendant of `Tc` but `Tb` is not.)*

As you may picture from the above outstanding piece of art, their management can quickly start to be tedious hence resource intensive.  
This resource usage (mostly RAM for storage and CPU to update them) impacts **every single node** not running with `-blocksonly` on the network, it is thus a DOS vector that must be limited. But how?

I can point you to the [bitcoin-core dev wiki](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining) which reports the word of [Suhas Daftuar](https://github.com/sdaftuar) -one of the main architects of the system that is currently in place- regarding the trade-offs of different approaches to usage limitation, but as a TL;DR:  
The mempool needs to be in phase with miner incentives (don't drop the highest-paying transactions), while limiting its footprint on network nodes. Therefore, two limits are in place for the two "views" relative to a transaction:

* The size limit, accounted for in virtual bytes, of both its descendants and ancestors.
* The count limit, accounted for in number of transactions, of both its descendants and ancestors.

> **Comments:**
> **username_0**: Thanks for your explanation and nice image. I understand now. One thing to note that I was originally confused about... when I would attempt to broadcast a transaction (txidA) that had 24 unconfirmed ancestors, I would get the error "too many descendants for tx <txidB> [limit: 25]". This confused me, but now I realize it's saying that the oldest ancestor of my new transaction (<txidB>) would now have too many descendants if I added my new transaction <txidA>. Its also true that txidA would have too many ancestors, but the code just happens to trigger first when checking txidB.  
> **username_2**: I love the graphic! You could get even more use out of the graphic by adding an example, e.g. "Ta and Tc are ancestors of Te, but Tb and Tf are not ancestors of Te".  
> **username_0**: +1 to username_2's suggestion. If i understand correctly:  - Ta has 0 ancestors, and has descendants Tb, Tc, Td, Te, and Tf ................  - The only ancestor for Tc is Ta, and Tc has descendants Td, Te, and Tf ..............  - The ancestors for Te are Tc and Ta and has Te no descendants ................ sound right?  
> **username_1**: Oops, overlooked it. Will address soon :)  
> **username_1**: @ username_0 this is right. I added @username_2's suggestion to comment the graphic.  
> **username_1**: @username_0 would you mind marking this answer as accepted if it answered your question?  

---

