● CPFP carve-out: in order to spend bitcoins, the transaction where you received those bitcoins must be added to the block chain somewhere before your spending transaction. That addition can be in a previous block or it can be earlier in the same block as the spending transaction. This protocol requirement means that a spending transaction with a high feerate can, through averaging, make it profitable to mine its unconfirmed parent transaction even if that parent has a low feerate. This is called Child Pays For Parent (CPFP).

CPFP even works for multiple descendant transactions, but the more relationships that need to be considered, the longer it takes the node to create the most profitable possible block template for miners to work on. For this reason, Bitcoin Core limits the maximum number and size of related transactions. For users fee bumping their own transactions, the limits are high enough to rarely cause problems. But for users of multiparty protocols, a malicious counterparty can exploit the limits to prevent an honest user from being able to fee bump a transaction. This can be a major problem for protocols like LN that rely on timelocks—if a transaction isn’t confirmed before the timelock expires, the counterparty can take back some or all of the funds they previously paid.

To help solve this problem, Matt Corallo has suggested a change to the CPFP policy to carve-out (reserve) some space for a small transaction that only has one ancestor in the mempool (all of its other ancestors must already be in the block chain). This accompanies a proposal for LN described in the News section of last week’s newsletter where LN would mostly ignore onchain fees (except for cooperative closes of channels) and use CPFP fee bumping to choose the fee when the channel was closed—reducing complexity and improving safety. However, to make this safe for LN no matter how high fees get, nodes need to also support relaying packages of transactions that include both low-feerate ancestors plus high-feerate descendants in a way that doesn’t cause nodes to automatically reject the earlier transactions as being too cheap and so not see the subsequent fee bumps. Whereas the carve-out policy is probably easy to implement, package relay is something that’s been discussed for a long time without yet being formally specificed or implemented.