Author: Bastien TEINTURIER 2020-04-22 08:55:42
Published on: 2020-04-22T08:55:42+00:00
The email thread discusses two attack vectors on the Lightning Network. The first attack vector involves an attacker intentionally delaying the confirmation of honest party transactions to affect inter-link timelock and provoke an unbalanced settlement for the victim. This type of attack relies on getting honest party transactions bounced off due to the attacker's transaction being already there. Two likely candidates for this type of attack are BIP 125 rule 3 and BIP 125 rule 5. The email provides a detailed scenario explaining how the attack would work, including how the attacker can broadcast its Pinning Preimage Tx on offered HTLC #2 output on Alice's transaction, with a feerate chosen maliciously to get into network mempools but never to confirm.The second attack vector involves a vulnerability in RBF Pinning HTLC Transactions in today's lightning protocol. The vulnerability arises when a lightning counterparty receives an HTLC from another party and broadcasts the commitment transaction. The solution proposed in the email is to add an RBF carve-out output to HTLC-Timeout or allow B to re-sign the B-side signature for a higher-fee version of HTLC-Timeout. Additionally, the email suggests that the Decker-Russell-Osuntokun channel sidesteps the issue of additional output that bloats the UTXO set and requires another transaction to claim later. The email concludes by highlighting the need to make HTLC-Timeout and possibly symmetrically, HTLC-Success fee-bumpable. It also highlights the disadvantage of C in a bidding war between C requesting miners to censor and B requesting miners to confirm. The email suggests that the issue is complicated and requires further attention.
Updated on: 2023-06-14T00:38:44.702771+00:00