Lightning replacement cycling attack
and future possible scenarios
I discussed with Giacomo Zucco about this attack in order to define what this is, how it is performed and what is the real risk (if exists) and compare to what has been told all around on social networks during current days. We tried to remain not too much technical in this article. This was the right opportunity also to discuss about possible future scenarios and upgrades in Lightning.
So let's separate things here as well that are a bit layered. First layer, the bug itself. It's a December 2022 confirmed bug, it's an attack that's not only old and mitigated already, but also quite absurd, in the sense that if you are a Leaf node, like a Phoenix customer, nothing can happen to you.
When attack is possible?
If you are a routing node and you do active routing, and if your attacker has two channels with you, which you don't know that they are both belonging to the attacker, and if those two channels have different lock times in a relevant way (if you have two channels with lock time very different) and if these two channels both with attacker attack you by colluding with a miner, (because if not otherwise you see it in mempool and you can stop it), and then they do a sort of transaction that doesn't show in your mempool until it's confirmed, then only in that case, they can only steal from you as much as you are routing.
So mitigation is basically a check that was already put in place: It's a check on lock times:
make lock times longer
keep lock times more symmetric
restrict maximum amounts of HTLC when you have to route with different lock times.
Some important actors in the Lightning network we were talking about it confirmed they already solved by applying the mitigation suggestions and are not basically attackable.
Mitigation or fundamental solution?
In various sources Antoine Riard wrote that even if it's mitigated, anyway in theory other more sophisticated variants are always possible, there's a kind of cat and mouse, it's not solved in a fundamental way, we have to make a change on-chain, to solve in a fundamental way.
It is not wrong what he says, but it's over-dramatized, so IMHO he has given rise to unwarranted alarmism.
We are talking about a very very rare non-general attack, affecting very specific cases, already mitigated, but which could theoretically be repeated in even more complex.
This has created a lot of FUD, and in particular some important magazines in this sector, decided to relaunch it with even more FUD, probably because they want to launch drive-chain and other nonsenses. It was relaunched by people from Bitcoin satoshi’s vision, from other shitcoiners saying that “a backdoor has been discovered” in Lightning network, that’s simply not true.
Obviously it can't be a backdoor also because it is not in an implementation, it is a problem of specifications, a specs issue, so obviously the backdoor idea is idiotic totally, it doesn't make really no sense at all.
What kind of protection we can set up?
Reduce max HTLC;
Enlarge CLTV delta;
In a routing professional node, you can choose to set a specific defense strategy. It is possible, for example, to assign a web trust type coefficient to the various nodes to open with, so if you have a stranger node, you can route with it but with lower max HTLC limits and higher CLTV delta, if you have known nodes instead, then do vice-versa. In this way the attack becomes more expensive.
Ideally for the attack to become infinitely expensive i should raise CLTV to infinity and lower the max HTLC to zero.
However at this point already HTLC is stuff that increases the complexity of Lightning design a lot, it's really complex stuff with a lot of difficult points.
This bug in my opinion should have made us reconsider, not now because now no real danger is there, but when we should still go from HTLC to PTLC we might also consider the fact that maybe it is an over engineering to do things atomic.
Infact a commercial payment is never atomic. What do I mean? I generally pay you and you decide whether to give me a service or not.
It is almost never technically atomic, I mean even when you pay for beer I pay you and the beer comes later, it's not atomic, because trade is never atomic in a real world. So, for this reason, the fact that payment is atomic is kind a redundancy. We can reconsider this in the future.
So actually the interesting thing about this bug is that it opens up some brain-storming about the overall design in the Lightning network, showing up how it could be improved in the future.
Another consideration is that a channel Lightning is a type of UTXO sharing, because it shares UTXOs. However it shares them between two people. No problem when onchain fees are low (like as today) but in a world where the on chain fees are equivalent a thousand dollars, a per transaction average open channel costs a thousand dollars and if you also share a cost of $500 each is a lot; to close a channel if one of the two is uncooperative it costs not $500 but it costs a thousand.
On the other hand, if you make a channel between a thousand people it costs a dollar each open the channel. When one of the nodes becomes not responsive, it will cost a dollar plus 1/1000 close so it costs a little more than a dollar, if even there was a sybil attack and even half of the nodes that opened the channel were non-responsive, the other half will have to pay two dollars each so it is feasible and carries no problems.
So in a future where on chain fees are high anyway UTXO sharing changes things and when we assume different opening and closing fees almost all these attacks of fee pinning will go pretty much to hell.
So the discussion opens up very interesting scenarios for the future. Anyway on the short term it's just a one year old attack already mitigated (even if unsolvable in a complete sense) that just gives us possible inspirations on future design that could also be impactful.
Attack dynamic details
About the attack dynamics that we do not covere in this article, you can consult this tweet that has also images and accurate description.
https://x.com/mononautical/status/1715736832950825224?s=20
About glossary used above:
An HTLC (Hash/Time Lock Contract) is a conditional payment from sender to receiver. It can be spent immediately by the receiver by revealing the preimage to a hash H, or reclaimed by the sender after some timeout.