Since 2015, Bitcoin Core has included a
-limitdescendantcount configuration parameter (added in this commit) that forbids a transaction in a node's mempool from having more than x descendants accepted into that mempool (default x is 25). I think this addresses two concerns:
Excessive package comparisons: for ancestor feerate mining, a node builds multiple different virtual packages containing related transactions and derives their package feerate. If the package feerate is higher than the feerate of the individual transactions contained within it, the node will prefer to keep and mine that package over the individual transactions. The more related transactions there are in a mempool, the greater the number of packages that need to be compared; given the choice of 25 as the value here, I'm guessing the number of comparisons that needs to be made isn't combinatorial but can be exponential in the worst case.
Wasted bandwidth and censorship: if a node accepts one parent with as many descendents as is possible to fit in its mempool, then a miner producing a block with a transaction that conflicts with the parent can invalidate the entire mempool. This can waste a huge amount of relay node bandwidth (~150 MB every 10 minutes times ~50,000 nodes is 540 TB per day, not including inv overhead). It may also be able to use this mechanism to prevent other people's unrelated transactions from confirming at low cost to the denial of service attacker.
Which of those concerns is the one that most motivates keeping this limit at 25? I realize the answer there might be opinionated (and so a poor choice for this site), but imagine that we had to disentangle the concerns and have two different limits: one for preventing excessive comparisons and one for reducing the liklihood of wasted bandwidth. In that case, what
limitdescendantcount values would we use for each of those different cases?