Topic: The end of Lightning Network? (Read 571 times)

and so we thought LN is a very good alternative when it comes to cheaper payment method. and now with this news, i don't think people will think of this network to be viable in the payment system anymore. people are looking for ways on how to get cheaper transactions via btc and now this option is out already. but in any case, i believe up until now, only few are using LN for their transactions so yes, it is no big deal.

and so we thought LN is a very good alternative when it comes to cheaper payment method. and now with this news, i don't think people will think of this network to be viable in the payment system anymore. people are looking for ways on how to get cheaper transactions via btc and now this option is out already. but in any case, i believe up until now, only few are using LN for their transactions so yes, it is no big deal.

initially yea. but these days majority of the liquidity is linked to 3 large companies. and they will want to further protect their locked liquidity by disavowing its customers control of the agreements/commitment states.

this topics flaw is not even a major problem but when lightning devs admit they cant fix something within their own network and resign. it shows not only they need to want bitcoin to fork to fix THEIR error. but also that when the other flaws get publicised which also cant be fixed. more and more will start to realise its time to break their sponsored contract. and try something new

time for them to scrap it and start afresh, new model, new method. les flaws, less bugs

we should not be forking bitcoin just to make a subnetwork function.. a subnetwork should function prebridge.. and then program itself on its side to interact with bitcoin

if they cant even have a working prototype thats secure. they failed at the first post

initially yea. but these days majority of the liquidity is linked to 3 large companies. and they will want to further protect their locked liquidity by disavowing its customers control of the agreements/commitment states.

this topics flaw is not even a major problem but when lightning devs admit they cant fix something within their own network and resign. it shows not only they need to want bitcoin to fork to fix THEIR error. but also that when the other flaws get publicised which also cant be fixed. more and more will start to realise its time to break their sponsored contract. and try something new

This puts some serious doubt on the future of lightning and the viability of it as a scaling solution.
What are your thoughts? Is there a path of recovery for developing scaling solutions?
And how about the years of waiting and supposed progress of development on the lightning network? Does it all go to waste?
For many, lightning network was the go to solution to bircoin's scaling issues.

I believe Lightning Network initially was designed for off-chain transactions with small or not too big value so how recently it becomes a big problem.

I would still be more concerned with someone stealing one of the RaspberryPi nodes in a box on my desk and getting my BTC that way then pulling this off.
It's just so out there as to be not something worth worrying about for the average user.

For the larger businesses running nodes I could see it being a concern, BUT since as pointed out there are some ways, admittedly non optimal ways but still ways, of mitigating it, once again not that big a deal

Why? You can just turn off your nodes. You don't have to close those channels. Let your users do that, so they will start betting, by closing their channels in panic, and setting higher and higher on-chain fees, and reaching levels, where a proper fee to get it included in the next block, will reach the holy "1000 satoshis per virtual byte" limit, or will exceed the amount locked in the channel.

And then, your side would be clear. Being offline is less serious crime than closing the channels by yourself, even if the final outcome is exactly the same. It is sad, that LN can be attacked just by being offline, but it is true, and many attacks can be done in this way.

14) This attack isn't easy. Pulling it off involves:
 - opening two channels with the victim.
 - routing a payment through them.
 - successfully replacement-cycling the victim's htlc-timeouts for Δ blocks.
 - without the victim discovering the htlc-preimage transaction.

I like what Jameson Lopp says though here:



https://twitter.com/lopp/status/1716022677515723107

For many, it seems that this is a big problem, but this can be used as a tool to spread FUD as well.

On the other hand, not all of us are very technical here, unless really a individual take time to exploit it and proved a point. But other than that, it has been identified and maybe a solution could be released very soon.

Not sure why some people are calling it dead already.

1. While he's a core dev, he's definitely not the only dev

2. Lightning has never been perfect. But while it technically works, it's simply not ready yet. There's a reason why I never recommended it to normies yet as of yet. But, let's not forget that —

3. Software can be improved

Not sure why some people are calling it dead already.

1. While he's a core dev, he's definitely not the only dev

2. Lightning has never been perfect. But while it technically works, it's simply not ready yet. There's a reason why I never recommended it to normies yet as of yet. But, let's not forget that —

3. Software can be improved

Lightning's fucked, but not dead. I don't see why it would be. There's just too much support for the network, and they're filled with capable devs that could take from where Riard will leave. Plus at the end of the day he's not the glue that puts everything together, long as there's people who are willing to improve upon Lightning Network cause just as what MK4 has said it's far from perfect, it will remain functional and pretty much alive. In the event that it does die, I don't think it connotes to anything other than previous efforts about Layer 2 solutions being moot.

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?

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.

Peter Todd mentioned potential fixes requiring soft forks on the mailing list - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022042.html

Shinobi says that the problem can be solved just with a few tweaks - https://twitter.com/brian_trollz/status/1715743794098753952

That does not sound "simple" at all.

Antoine Riard is a senior Lightning dev, not just some junior dev.

Higher time_lock_delta leads to longer time for locked funds. That's a tradeoff.

Rebroadcasting with higher fees: Also known as "defensive fee mitigation". I suppose that's doable to keeping spamming the mempool dozens of times until the attacker gives up. Would be a simple client update, but it introduces additional spam and client complexity.

I'm going to wait until the experienced Lightning devs test this attack and report back the costs of attacking and defending. This is beyond my level of understanding.

It sounds like they're going to look for a sustainable fix, but it'll take several months of testing and implementation. In the meantime, I would refrain from keeping high value on Lightning, like everyone should've been doing from the start.