CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

The rule has been added to GitHub in an attempt to pave the way for more robust CPFP of on-chain contracts (Lightning commitment transactions). Johan Torås Halseth is questioning whether the special case rule should have been relaxed a bit to avoid adding a CSV to all outputs. Instead, he suggests letting the rule be that the last transaction which is added to a package of dependent transactions in the mempool must not have more than one unconfirmed parent. However, this would allow an attacker to exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases, so it's unclear if this is a problem with the current mempool acceptance code in Bitcoind. Matt Corallo argues that the fact there is a size limitation on the transaction that spends for carve-out purposes only effects how many other inputs/outputs can be added, but doubts its ever going to be a large enough number to matter. Rusty Russell says the Lightning close algorithm would work if they allowed a simplified Replace-by-Fee (RBF) where "you can replace if feerate is higher, new tx is in first 4Msipa of mempool, old tx isn't."