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

In an email exchange, Matt Corallo and Rusty outline a lightning close algorithm. The simplified Replace-By-Fee (RBF) suggested by Rusty allows someone 100k of free transaction spam. However, it is simple and can be further restricted by marking the unilateral close as "gonna be pushed" and limiting the child tx weight to 5kSipa in that case. The lightning close algorithm involves giving bitcoind unilateral close, asking for the current expedited fee, giving bitcoind child "push" tx at that total feerate, then checking if the next block contains the unilateral close tx. If not, repeat the process. Despite the possibility of adding RBF, there are issues with block time variance, making it difficult to guarantee top 4MWeight will get confirmed within a few blocks, which is why Rusty has suggested the lightning close algorithm instead.