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

In a recent discussion, Matt Corallo highlights the difficulty in defining a criteria for "near the top of the mempool," as it can be problematic for large batched transactions where a single counterparty can prevent confirmation. He notes that Lightning's requirements are different since it seeks certainty that a transaction will confirm by some deadline, rather than just having a high probability of confirmation. However, Rusty disagrees and believes that the two are not very different in practice. He suggests defining "top of mempool" as "in the first 4 MSipa," which is the next block, and only allowing RBF if the old package wasn't in the top and the replacement would be. This seems incentive-compatible and better than the current scheme of always overpaying and hoping. Although an attacker can make you pay high fees, you can still decide at the time based on whether the expiring HTLC(s) are worth it. Ultimately, Rusty thinks that whatever is simplest to implement should win, but he is not in a position to judge that accurately.