Published on: 2018-11-23T23:17:34+00:00
In recent discussions on the Lightning-dev mailing list, the importance of RBF-able punishment transactions in preventing theft attempts was highlighted. While the commitment transaction being RBF-able is not crucial, having an RBF-able punishment transaction that spends the commitment transaction is essential. This allows for immediate confirmation of the old commitment via CPFP and requires only a single signature from one node.Cezary Dziemian raised concerns about outdated commitment transactions and the potential for attackers to commit such transactions and spam the bitcoin mempool with transactions to increase fees. He questioned whether penalty transactions, which are used to claim outputs from outdated commitment transactions, can be replaced by fee (RBF) and if this behavior is implemented as default in popular LN implementations like c-lightning, eclair, and lnd.René Pickhardt responded, explaining that while RBF may be possible for penalty transactions, it may not be practical due to the need for a signature from the former channel partner. He also mentioned that there is currently no way to CPFP the output of a commitment transaction because of the timelock on the output. However, a proposal has been made for BOLT1.1 to include a third output in commitment transactions that anyone can spend (OP_TRUE) and which has no timelock, allowing for CPFP.In an email exchange between Cezary Dziemian and Rene Pickhardt, Cezary asked about increasing fees when they suddenly rise and how penalty transactions work. Rene explained that RBF is not possible in the case of a unilateral (force) close because the signature of the former channel partner is required. He mentioned that for BOLT1.1, a third output in commitment transactions will be added, which anyone can spend, enabling CPFP. He also mentioned that there is an economic incentive to quickly get the penalty transaction mined by using high fees or relying on a large number of transactions to RBF.In a discussion thread on the Lightning-dev mailing list, Cezary Dziemian sought clarification on how commitment and penalty transactions work in the Lightning Network. He referred to an article he had read that explained the need for a child transaction containing one's signature and secret to claim former channel partner funds. René Pickhardt responded, stating that RBF would require the signature of the former channel partner, which may be unlikely to obtain in a force close scenario. He also mentioned the issue of CPFP requiring spending one's output, which is not possible due to the timelock. However, for BOLT1.1, a third output will be added to commitment transactions, allowing for CPFP by anyone. This output will have no value except as a fee for miners.In the recent email exchange between Cezary and Rene, the issue of unilateral force close in the Lightning Network was discussed. RBF for a commitment transaction would require the signature of the former channel partner, which is unlikely in a force close situation. CPFP would require spending one's output, which is not possible due to the timelock. It was agreed during the last lightning developer summit that for BOLT1.1, a third output will be added to commitment transactions, enabling anyone to CPFP it. Miners could collect this output as a fee. Details about this proposal can be found in the Lightning Specification 1.1 Proposal States section of the lightning-rfc git repo. The conversation did not specify the exact penalties being referred to or any common approach among major implementations.Cezary Dziemian has two questions related to penalty transactions. He wonders if his node automatically commits a penalty transaction when someone commits an obsolete commitment transaction and if his node can use RBF to increase fees if they suddenly rise. He also asks if there is a common approach among the major three implementations (c-lightning, eclair, lnd) and if there is a specific time or block limit for committing penalty transactions.
Updated on: 2023-07-31T20:58:20.899721+00:00