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 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]"


"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?

1 Answer 1


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):

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 handle chain reorganization) 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 which reports the word of Suhas Daftuar -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.
  • 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
    Oct 6, 2020 at 16:54
  • 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".
    – Murch
    Oct 13, 2020 at 19:05
  • +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
    May 7, 2021 at 17:20
  • Oops, overlooked it. Will address soon :) May 7, 2021 at 17:23
  • @ deezy this is right. I added @Murch's suggestion to comment the graphic. May 9, 2021 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.