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

The email thread discusses the possibility of relaxing the Carve-Out rule for on-chain contracts, which currently requires at least one non-CSV output per party. Johan Torås Halseth suggests changing the rule to allow for more robust CPFP (Child-Pays-For-Parent) of Lightning commitment transactions by requiring only that the last transaction in a package of dependent transactions have no more than one unconfirmed parent. Matt Corallo questions how this would change anything since the current rule already allows for adding inputs/outputs as long as there is an output available without any descendants. Rusty Russell proposes a simplified RBF (Replace-By-Fee) where transactions can be replaced if the new transaction has a higher feerate and is in the first 4Msipa of the mempool, and the old transaction isn't. The discussion also touches on potential spamming issues with the proposed changes and the need for marking unilateral close transactions. There are concerns about the potential impact on the mempool acceptance code in bitcoind, but it's noted that evicting transactions based on feerate when the max mempool size is met should handle this.