Clarifying descendants/ancestors in error cases for too-long-mempool-chain

Question

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

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?

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

         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 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.