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

Summary:

The email thread discusses a proposal to tweak Lightning's commitment transaction to have two small-value outputs which are immediately spendable, one by each channel participant. This would allow them to chain children off without allowing unrelated third-parties to chain children. The proposal aims to address the CPFP security model considerations. However, it is pointed out that this proposal does not change the current status quo where a commitment transaction may remain unable to be broadcast if feerates spike much higher than the feerate negotiated at the time of construction.The proposal suggests a small tweak to the anti-DoS CPFP rules in Bitcoin Core/BIP 125. In the example provided in the email, output Z must be CSV-delayed to make the proposal secure. Otherwise, Alice could use output A to pin the transaction and then "use up" the proposed "last-transaction" rule by spending output Z. This would leave Bob unable to spend output B without meeting the (expensive) RBF criteria.Furthermore, Russell O'Connor argues that the two-output scheme can address the specific attack without tweaking the RBF rules of BIP 125 since it does not involve RBF at all. He provides an example of how a malicious party could attempt to pin a 1k-vbyte unconfirmed transaction using a 10k-vbyte transaction. Bob wants to CPFP to increase the effective fee rate of TX0 to 3sats/vbyte using output B. He attaches a 1k-vbyte transaction, TX2, to output B with a fee of 5ksats. This ought to create a new TX0-TX2 package with a 3sat/vbyte fee rate. However, TX1 has now been excluded from the package containing TX0, but it hasn't been replaced, so the RBF rules from BIP125 don't apply.

Updated on: 2023-05-20T18:29:17.472047+00:00