So can nobody on here actually explain what the issue is in plain words?
Unless someone can actually describe what the problem is its hard to tell if this is just a lone dev throwing up his hands at a problem and storming out dramatically (not the first time that will have happened in the Bitcoin world) or if its actually a serious problem for LN.
What's the attack? What does it compromise? How hard is it to do? How bad is the effect? How likely is it to occur?
I read what Antoine wrote, I didn't understand. I tried looking for a simpler explanation. Not that I understand the problem now, but at least it gave me a little idea. To a non-technical person, this is indeed hard to digest. But it seems Antoine is making it appear as if it's something too huge of a problem to successfully address. This is the impression because when I read other experts' opinions, it seems they're not really as bothered as Antoine.
Here's a simpler explanation of the problem by mononaut over twitter. This isn't everything so you may continue reading there
https://twitter.com/mononautical/status/1715736832950825224.
How does a lightning replacement cycling attack work?
Imagine Bob is routing a lightning payment from Alice to Carol.
While in flight, the payment is protected by HTLC outputs in his pre-signed channel commitments with each peer.
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.
By securing the HTLC on each hop with the same hashlock, payments can be routed atomically.
Carol can't claim the outgoing HTLC without revealing the preimage, which Bob can then use to redeem the incoming HTLC from Alice.
At least that's the theory...
To ensure Bob has time to react if something goes wrong, the timelock on the outgoing HTLC expires first at some block height T.
Then the timelock on the incoming HTLC expires at some later height T+Δ, after which Alice can reclaim her money.
OK, so here's the attack:
Remember Bob has HTLCs pending in two channels.
One outgoing HTLC to Carol, which expires at block T, and one incoming HTLC from Alice, which expires at block T+Δ.
At block T, Carol still hasn't revealed the preimage to settle the payment, so Bob is forced to time it out on-chain.
He broadcasts the commitment tx to close his channel with Carol, and once it confirms sends an "htlc-timeout" tx which spends the HTLC to reclaim his funds.
Unbeknownst to Bob, Alice and Carol are colluding to steal his money.
They have prepared for the attack by broadcasting a chain of two transactions with low fees, apparently unrelated to the lightning channel, which we'll call the "cycle parent" and "cycle child".
As soon as the attackers see Bob's htlc-timeout transaction hit the mempool, they broadcast an "htlc-preimage" transaction, which spends both the HTLC output (using Carol's hash preimage) and an output from the cycle parent.
Since this htlc-preimage transaction pays a higher fee rate and spends the same inputs, it replaces both the cycle child and Bob's htlc-timeout transaction in the mempool.
If Bob sees this, he can take the preimage and use it to immediately redeem the incoming HTLC from Alice.
So the attackers broadcast a new transaction replacing the cycle parent.
The htlc-preimage depends on that for one of its inputs, so is also evicted from the mempool.
At the end of this cycle, the HTLC from Bob's channel with Carol ends up unspent, and no trace of the htlc-timeout and htlc-preimage transactions remain in the mempool.
The attackers repeat the cycle to eject Bob's htlc-timeout transaction every time he rebroadcasts it.
If they prevent it getting mined for another Δ blocks, Alice can timeout the HTLC on the other channel, and leave Bob out of pocket for the entire value of the payment.
