Allow one extra single-ancestor transaction per package (mempool)

Jun 26, 2019

https://github.com/bitcoin/bitcoin/pull/15681

Notes

A child transaction is a transaction that spends one or more of the UTXOs from another transaction, called its parent transaction. More generally, a descendant transaction spends a UTXO from a transaction that derives from one or more previous transactions, called ancestor transactions.
In a valid Bitcoin block chain, parent transactions must appear before child transactions. This makes sense: if a child transaction appeared first it’d be spending a UTXO that doesn’t exist and so the child would be invalid. As a corollary, all ancestor transactions must appear in the chain before any descendant.
These ancestor rules make mining more complicated. You can’t just add any transaction to your block proposal—if you want to add a child transaction, you must first add any of its unconfirmed ancestors. Prior to PR #7600, this meant Bitcoin Core would only consider a child transaction for inclusion in a block if all of its parents were either part of the block chain (confirmed) or already paid high-enough feerates to be included in the block proposal on their own.
That old mining strategy doesn’t maximize profits for miners: if a child transaction pays enough fees, the average feerate of mining both transactions can be higher than the feerate of the parent alone. In other words, the Child Pays For [its] Parent (CPFP). This applies to longer sequences of ancestors as well. CPFP is not only profit-maximizing for miners but it provides a method of fee bumping to users—users can create high-fee descendants in order to get low-feerate ancestors confirmed.
To implement this profit-maximizing strategy, Bitcoin Core tracks transaction packages, which is the set of transactions that needs to be added to a block for any particular transaction to be confirmed, plus the overall size and average feerate of those packages. You can see package information for your current mempool by running the following commend (warning: it’ll take a while if your mempool has lots of transactions in it): bitcoin-cli getrawmempool true
Calculating package information requires CPU and storing it requires memory. Although the amounts of each resource used per transaction don’t seem significant, it’s worth noting that Bitcoin Core currently defaults to keeping up to about 100 blocks worth transactions in memory (several hundred thousand transactions), any of which might need to be updated when a new descendant arrives.

To bound these costs, when CPFP mining (ancestor feerate mining) was implemented in PR #7600, it came with limits on the maximum number and size of related transactions that would be allowed into a package-using mempool. The current limits are:

$ bitcoind -help-debug | grep -A3 -- -limit
  -limitancestorcount=<n>
       Do not accept transactions if number of in-mempool ancestors is <n> or
       more (default: 25)

  -limitancestorsize=<n>
       Do not accept transactions whose size with all in-mempool ancestors
       exceeds <n> kilobytes (default: 101)

  -limitdescendantcount=<n>
       Do not accept transactions if any ancestor would have <n> or more
       in-mempool descendants (default: 25)

  -limitdescendantsize=<n>
       Do not accept transactions if any ancestor would have more than <n>
       kilobytes of in-mempool descendants (default: 101).