[Lightning-dev] Breach tx vulnerability & CPFP attack

Jérôme Legoupil jjlegoupil at gmail.com
Mon Mar 28 09:19:42 UTC 2016

Alice has a channel with Bob, lets say 50BTC on each side, and after some time, the channel ends up with 100BTC in Bob’s favour (so Alice has 0BTC in that channel)

Alice broadcasts the obsolete 50/50BTC commitment tx as well as her revocable tx : Multisig tx -> Alice 50BTC, OP_CSV.

When Bob sees that, he broadcasts his breach tx, put it’s not being picked up in blocks. Why ? Alice followed up by broadcasting (or privately sending to major pools) the tx : Alice 50BTC -> Alice 25BTC. She is offering miners to share Bob’s 50BTC with her. 

Alice has nothing to lose behaving this way since she had nothing left in the channel anyways and miners have a strong financial incentive to wait and hope to include Alice’s 25BTC offer instead of including Bob’s worthless breach tx.


To defend against this attack Bob should do 1) and 2) :

1) Bob should not allow any of his channels to drop below some certain amount, like 10% or something, in order to keep some garanty from Alice, so she won’t have an incentive to behave maliciously. Unfortunately this reduces the channels efficiency but I think this example shows exhausted channels are insecure. 

2) Bob should monitor the blockchain permanently and as soon as he detects an obsolete commitment that is confirmed, he should immediately broadcast his breach tx and he should assume Alice is offering miners to collude with her. Therefore, he should engage ASAP in a scorched earth policy by broadcasting a replace-by-fee CPFP tx to himself, offering Alice’s share to miners. He can increase the fee until it is picked up. He has an advantage over Alice during the contest period but his advantage diminishes as the contest period comes near the end. If he wins, Alice loses her 10%, but 10% may not be enough to outbid Alice and Bob may end up losing money. 

3) Bob has better chances to win at a lesser cost, the longer the contest period is. If the channel contains high values, the contest period could be chosen higher than usual at setup to make it more secure.

I am not sure this defense is really convincing but that’s the best I could come up with. Any thoughts ? 


More information about the Lightning-dev mailing list