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

Summary:

In an email exchange between ZmnSCPxj and Bob McElrath, the topic of using SIGHASH_SINGLE was discussed. Bob shared that he had long thought about utilizing this feature so that either party can add inputs to cover whatever fee they want on channel close without the need for pre-planning at setup. He also suggested that for Lightning, cross-signing would be necessary, wherein Alice signs her input and Bob's output, while Bob signs his input and Alice's output. This would discourage the two parties from picking apart the transaction and broadcasting one of the two SIGHASH_SINGLE's in a Lightning transaction.The email also included a message from Matt Corallo via bitcoin-dev, discussing how Lightning and other similar systems work by exchanging pre-signed transactions for future broadcast and how it requires predicting what the feerate required for timely confirmation will be at some point in the future or utilizing CPFP and dependent transaction relay to allow parties to broadcast low-feerate transactions with children created at broadcast-time to increase the effective feerate. The email further discussed the security model around CPFP and how tweaking Lightning's commitment transaction to have two small-value outputs which are immediately spendable, one by each channel participant, allowing them to chain children off without allowing unrelated third-parties to chain children. It also proposed a small tweak to the anti-DoS CPFP rules in Bitcoin Core/BIP 125. As an alternative proposal, discussions were held around solving the "RBF-pinning" problem by allowing transactors to mark their transactions as "likely-to-be-RBF'ed", which could enable a relay policy where children of such transactions would be rejected unless the resulting package would be "near the top of the mempool".

Updated on: 2023-06-13T15:48:10.441038+00:00