By Bitcoin Aikakauslehti - 6 kuukautta sitten - Lukuaika: 6 minuuttia
Post mortem salamakorvauspyöräilyhyökkäyksestä
So a lot of noise has been made around the Lightning vulnerability recently disclosed by Antoine Riard. Many people are claiming the sky is falling, that Lightning is fundamentally broken, and nothing could be further from the truth. I think part of the problem is that people don't really understand how this vulnerability works, firstly, and secondly many people don't understand how this individual vulnerability overlaps with other known issues on the Lightning Network that have known solutions.
So first, let's go through and try to understand the vulnerability itself. When a Lightning payment is routed across the network, one thing that is key to understand is how the timelocks for refunding a failed payment work. The hop closest to the receiver has a timelock of 'x', and every hop going back to the sender has one of 'x+1', 'x+2', and so on. The timelocks get progressively longer as you go each hop from the receiver back towards the sender. The reason for this is that if a payment reaches the receiver, but some problem stops the preimage from propagating all the way back to the sender, the hop where it stopped has time to enforce it on-chain, and put the preimage there that all preceding hops need to confirm the payment. Otherwise someone in the middle, where the failure happens, could have their outgoing hop claim the funds with the preimage, and the hop that forwarded it to them claim it with their refund path, and leave that person in the middle shit out of luck having lost funds.
Replacement Cycling Attack on monimutkainen tapa yrittää saavuttaa täsmälleen tämä ei-toivottu tulos, jolloin kohdesolmu menettää rahaa, kun lähtevä hyppy vaatii varat onnistuneella tapahtumalla ja saapuva hyppy hakee varoja palautustapahtuman kautta. Tämä edellyttää uhrin solmun pysäyttämistä ja esteitä näkemästä esikuvaa onnistuneesta tapahtumasta toisella puolella ennen kuin aikalukko on umpeutunut toisella puolella, jotta he voivat hakea hyvitystä siellä.
This requires a very targeted and complicated game of manipulating the victim's mempool. Let's look at the actual transaction structure involved here. You have the commitment transaction, which is the main transaction representing the Lightning channel state. It has an output for each side of the channel representing funds completely under the control of one member or the other, and outputs for each HTLC in the process of being routed. These outputs are the ones we are concerned with. Each HTLC output can be spent either immediately at any time with the preimage from the receiver, or after the timelock expires on the refund.
Hyökkäys edellyttää, että pahantahtoisella osapuolella tai kahdella salaliittoosapuolella on kanava uhrien solmun molemmilla puolilla, joka reitittää maksun. Joten Bob, uhri, saa kanavan hyökkääjien Alicen ja Carolin kanssa, ja maksu ohjataan Carolilta Bobille Alicelle. Muista nyt, että Liisan ja Bobin välinen aikalukitushyvityspolku vanhenee ja tulee voimaan ennen Carolin ja Bobin välistä hyvitystä.
The attackers route a payment through Bob, and then Alice will refuse to send Bob the preimage to finalize the payment when she receives it. What Bob will do now is wait until the timelock window expires between himself and Alice, and go to broadcast the channel commitment transaction and refund transaction to get it confirmed before the timelock window expires. What Alice will do is then go to spend the preimage transaction to claim the funds with an output unrelated to the channel, and right afterwards doublespend the second input in the preimage success transaction. The goal here is to evict Bob's timeout transaction from the mempool, but also evict the preimage success transaction so Bob doesn't see it. If he does, he will learn the preimage and can simply claim the funds in his channel with Carol before her timeout transaction is valid to spend.
Alice and Carol have to do this on a consistent basis, everytime Bob rebroadcasts his timeout transaction with Alice, until the blockheight passes where Carol's timeout transaction is valid. Then they can submit the success transaction on Alice's side, and the timeout transaction on Carol's side, and leave Bob holding the bag having lost the value of the payment he was routing.
The problem with this is two fold. Firstly, the victim's Bitcoin Core node must be specifically targeted to ensure that at no time does the preimage success transaction propagate into their mempool where their Lightning node can acquire the preimage. Secondly, if the second transaction Alice uses to evict the preimage transaction is confirmed, Alice incurs a cost (remember, the idea is to replace the timeout transaction with the preimage, so that is evicted from the mempool, then replace the preimage transaction with the second one double-spending the additional input in the preimage transaction). That means every time Bob re-broadcasts his timeout transaction, Alice has to pay a higher fee to re-evict it, and when that is confirmed she actually incurs a cost.
So Bob can force Alice to incur a big cost simply by regularly rebroadcasting his timeout transaction with a higher fee, meaning if the payment HTLC output is not worth significantly more than the fees Alice could incur, the attack isn't economically worthwhile to pull off. It would also be possible to prevent the attack completely by changing how HTLC success and timeout transactions are constructed. By using the SIGHASH_ALL flag, which means the signature commits to the entirety of the transaction and becomes invalid if the tiniest detail (like adding the new input in the preimage transaction required for this attack) is changed. This wouldn't work with current version of Lightning channels using ankkurilähdöt, but it would solve the issue entirely. Peter Todd has also proposed a new consensus feature that would entirely solve the issue, essentially a reverse timelock, where the transaction would become invalid jälkeen tietty aika tai lohkokorkeus sen sijaan, että se olisi voimassa sen jälkeen. Näin pitkälle meneminen ei kuitenkaan ole mielestäni välttämätöntä.
Simply rebroadcasting your transaction regularly with a slight fee bump is a massive mitigation of the attack, but there are also numerous dynamics that just make it not a serious issue regardless. First, if you aren't a routing node, this isn't really a serious issue. So most end users are safe from this attack. Secondly, there are many reasons why nodes do not allow any random person to open channels to them. Large nodes are very selective about who they peer with, as random channels not managed efficiently or professionally have a cost in the form of sunk or wasted capital in unused channels. So any large node that would make a juicy target for this attack is not trivial to even get connected with in the first place, let alone connect to them with multiple channels to pull off the attack in the first place. Lastly, as I've written about in the past, other unrelated attacks possible on the network are already necessitating filters and restrictions in how nodes choose to handle HTLCs they could forward. I.e. limits on the size of payments they will forward, how many they will allow at any given time, etc. So even if you can open a channel with a node worth attacking, as the network evolves there will be more thought through criteria and filters for deciding whether to even forward a payment in the first place.
Kaiken kaikkiaan tämä on oikeutettu ongelma ja mahdollinen hyökkäys, mutta sekä suorien lievennysten että hyökkäyksen vuorovaikutuksessa muiden ongelmien ratkaisujen kanssa pitkällä aikavälillä tämä ei ole ratkaisematon ongelma. Se on oikeutettu ongelma, ja sen hylkääminen puhtaasti FUD:na ei ole tarkka reaktio, mutta väittää, että taivas putoaa ja Lightning Network protokollana on tuomittu, on paljon liioittelua.
Aika kuluu eteenpäin, törmäämme ongelmiin ja korjaamme ne ongelmat sitä mukaa kun niitä tulee. Kuten meillä aina.
Alkuperäinen lähde: Bitcoin aikakauslehti