lightning-dev

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

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

In an email conversation among developers, the potential impact of relaxing the carve-out rule in Bitcoin's mempool limits was discussed.

David A. Harding pointed out that this change could allow for the free relay of large amounts of data, potentially exceeding the default maximum mempool size. Johan Torås Halseth raised concerns about the cost of relaying data if all limits were removed. Matt Corallo suggested increasing the carve-out limit to support the current Lightning Network protocol.The discussion also touched on the feasibility of a simplified Replace-by-Fee (RBF) scheme and the need to lower the default minimum fee in Bitcoin Core. There were discussions about implementing a tree structure for HTLCs, relaxing the carve-out rule, and utilizing a Lightning close algorithm. The proposed changes aimed to improve efficiency and mitigate potential spamming issues. However, there were concerns about the impact on the mempool acceptance code in bitcoind.The email thread also explored the possibility of relaxing the Carve-Out rule for on-chain contracts and implementing a simplified RBF scheme. Johan Torås Halseth suggested changing the rule to allow for more robust CPFP of Lightning commitment transactions. Rusty Russell proposed a simplified RBF scheme with specific conditions for transaction replacement. There were discussions about potential spamming issues, marking unilateral close transactions, and the impact on the mempool acceptance code.The email exchange highlighted the ongoing efforts to optimize the mempool and address the challenges associated with OP_SECURETHEBAG and RBF. Developers proposed various solutions, including changes to the carve-out rule and the implementation of a lightning close algorithm. The discussions emphasized the need for simplicity, feasibility, and compatibility with the Lightning Network protocol.Matt Corallo has proposed a solution to the Replace-by-fee (RBF) problem in the Lightning Network. His proposal involves allowing transactors to mark their transactions as "likely-to-be-RBF'ed" to enable a relay policy where any children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". While this theoretically prevents consistent attacks, there is still a low probability of executing such attacks in case of feerate spikes right after broadcast. Corallo believes that his proposal is incentive-compatible and addresses the issue of adding too many transactions to the UTXO set.The Lightning Network has been facing problems with the security model around Child Pays for Parent (CPFP). This has led to channel failures and difficulties in preventing third parties from delaying the confirmation of commitment transactions. To address this, Corallo suggests tweaking Lightning's commitment transaction to have two small-value outputs that are immediately spendable by each channel participant.Another alternative proposal discussed is to mark transactions as "likely-to-be-RBF'ed" to enable a relay policy where children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". Although this theoretically prevents consistent attacks, there is still a low probability of executing such attacks in case of feerate spikes right after broadcast.Overall, these proposals aim to improve the security and efficiency of the Lightning Network by addressing the issues related to RBF and CPFP.

Discussion History

0
Matt CoralloOriginal Post
November 29, 2018 19:37 UTC
1
December 2, 2018 15:08 UTC
2
December 4, 2018 03:33 UTC
3
January 7, 2019 15:18 UTC
4
January 8, 2019 05:50 UTC
5
January 8, 2019 14:46 UTC
6
February 13, 2019 04:22 UTC
7
October 24, 2019 13:49 UTC
8
October 24, 2019 21:25 UTC
9
October 25, 2019 07:05 UTC
10
October 25, 2019 17:30 UTC
11
October 27, 2019 19:13 UTC
12
October 27, 2019 22:54 UTC
13
October 28, 2019 09:45 UTC
14
October 28, 2019 17:14 UTC
15
October 30, 2019 07:22 UTC