The end of Lightning Network?

[Blaze Giovanni]

3. Software can be improved

This is what I thought.
I've not used it before but I've read a lot about it and it seems interesting. Technologies don't just become perfect from inception, it goes through phases. If you're waiting for a thing to be perfect before inventing it then we might actually not have any inventions at all.
This is a software that can get better with time and would always be updated. And we know how innovative technology can get so that means it would always be updated and worked on even after it's starts working perfectly.
Saying it's dead is reaching.

[1714686556]

1714686556

[1714686556]

1714686556

[1714686556]

1714686556

[1714686556]

1714686556

[DaveF]

Then you come in one morning and close all the channels to nodes that are not yours at once.

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.

Just flipping the power switch and making everyone else force close would probably cause a lot more disruption since your nodes are offline. And a ton of speculation as to what happened.

Closing down the channels would show that you attacked it.

In the end it does not matter, it would take a while for the LN to recover.

Flipping the switch would also cost you since you get the force close penalty from the nodes that are not yours.

Shrug, as I said. Not something to worry about. Could also do the same thing with mining in general.

-Dave

[Casdinyard]

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.

Too much sensationalization and fearmongering for a topic that's not really that scary when you look at it with a magnifying glass.

[BlackHatCoiner]

There are clearly some fundamental limitations with lightning, due to its design. As I have told multiple times already, the basic problem is that it is very unattractive for the average, non-techie Joe, because it requires him to study a little bit of how it works, but more importantly because of running a machine all day long. This is orders of magnitude more of a burden than the SPV solution.

I wouldn't worry for the retiring developer. Lightning does have a brighter future than currently, but again limited. We will sooner or later opt out for other sidechains (or drivechains).

[Primese]

This seems very serious, at least for those with high-value channels.

I'd like to see some cost-analysis for this kind of attack. What's the cost of running the attack, and at what point does the attack become profitable under different scenarios:

1. victim does not detect the attack
1. victim is not using automation and defends against it manually and slowly

[Primese]

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

Lightning is not dead, and this is getting silly as shit at this point. The solution to this issue is as simple as extending timelocks and rebroadcasting transactions regularly with a slight fee bump, or just handling pre-signed TXes in a different way.

The sky isn't falling.

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.

[HmmMAA]

There are a lot of ways to attack BTC and the Lightning Network. Most of them are so esoteric / expensive / just about impossible to implement as to not be worth it.
-Dave

There is a main difference in attacking bitcoin compared to attacks in any layer . Best thing you can do is make a double spend of your own money . So that double spend has to be more profitable than the cost ( hardware cost + energy spend ) of the attack  . And even if you decide to make an unprofitable bet trying to destroy the network , honest nodes can reorg the chain and leave you with a move that produced zero profit and a massive loss . Attacking base layer will always have a much higher economic cost than attacking other layers . That's the brilliance of the invention . 

[alani123]

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

Lightning is not dead, and this is getting silly as shit at this point. The solution to this issue is as simple as extending timelocks and rebroadcasting transactions regularly with a slight fee bump, or just handling pre-signed TXes in a different way.

The sky isn't falling.

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.

Indeed, if this was a simple issue, why not integrate a solid base in the project you're building from the beginning? 5000 BTC locked in this system is no game.
Building on production with millions at stake doesn't sound like something bitcoin should ever be doing. How are we going to defend the labels "future of money" and "digital gold" like this? It simply makes no sense... With such serious flaws lightning should have just been a testnet beta.

[seoincorporation]

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

Lightning is not dead, and this is getting silly as shit at this point. The solution to this issue is as simple as extending timelocks and rebroadcasting transactions regularly with a slight fee bump, or just handling pre-signed TXes in a different way.

The sky isn't falling.

It sounds like someone finds a bug and had to make some noise about it to make the devs make some changes, but as they mention "The sky isn't falling", but is a nice discovery. That guy should get a bug bounty.

We must keep in mind that if the bug is that critic then the blockchain would stop working, i mean if that guy could take all the mempool then he should do it just to test his theory. But there are some white hacks who always do the right think and report the bug before the attack.

[thecodebear]

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?

[Fundamentals Of]

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.

[JollyGood]

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

How much impact can one core dev have on the project if he pulls out? It will probably allow for other devs to put forward different likelihoods of how to go forward. Maybe other devs can start finding workarounds or solutions. It may end up being one temporary solution to another but if it works Lightening users will not complain too much.

How many normies actively use lightening in ratio to transaction?

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.

That cannot be denied, Lightening does have a lot of support and it is used more commonly than before therefore it is going to continue. Some of the noises about it becoming a relic of the past soon are somewhat premature but they will not stop until there is improvement to show it is capable of functioning more widely.

[KingsDen]

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

1. There's always this strong vibration if the core developer leaves. He might not be the finest developer, but when the soldier who pulled the first shot is down, the zeal to soldier on is always not assured.

2. No technology ever came in a perfect form, even the bitcoin is still in beta version. Continuing on decentralisation will do the wonders.

3. Yea, we are expecting improvements but I lost some confidence in LN during the event of mempool congestion that skyrocketed the transaction fees. At that time that the LN was needed most, it didn't help much.

[TravelMug]

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.

[philipma1957]

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.

So let's see some dedicated attacks wrecking LN seems to me that if LN is wrecked 4 people with 5 btc combined could lay some nodes to waste. We may as well find out now rather than letting the problem stay hidden and dormant.

I say white hatters attack LN by this method and show us LN is dead.

[DaveF]

mononautical on twitter sums it up nicely:

https://twitter.com/mononautical/status/1715736871534264818

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 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.

-Dave

[DapanasFruit]

In the past years, I heard many good things that can supposedly come out once the Lightning Network would be fully implemented and be adopted by many for transactions. This is one thing that we are pinning our hope that can translate massive and mainstream adoption for Bitcoin - most especially with small everyday transactions. I am then wondering...is this defect something that is beyond repair for one of its developers named Antoine Riard to disassociate himself with the project instead of coming up with the possible solution?

[karabiber]

Then you come in one morning and close all the channels to nodes that are not yours at once.

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.

The Lightning network does not depend on centralized parties. Anyone with Bitcoin can channel it to any node and use it completely unauthorized. On the other hand, there are of course nodes that act as "hubs" with excess liquidity for routing. But there are still many options for payment paths to the same destination. You can also choose to ignore large nodes for routing if you are concerned about centralization.

[franky1]

funny part
lightning advocates wanted RBF enabled on the bitcoin network to make pre-confirm transaction handling non-trusted on the bitcoin network, just so they can advertise a pre-confirm transaction handling feature on their crappy subnet.

now they admit their desire for RBF is causing people to scam scheme and steal funds from their crappy subnet and they cant do anything about it just within their crappy subnet without forking bitcoin again

..
i predict the next part will be having to raise crappy subnet fee's to sway people from starting low and RBF'ing until theft... but then want to demand bitcoin network fee war to make bitcoin fees extremes just to make crappy subnetwork seem discounted

sounds like an endless snowball avalanche of bad work arounds rather than having a subnetwork that simply does as advertised/promised in a secure way in-of-itself

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

[SquirrelJulietGarden]

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

I don't see people use Bitcoin Lightning Network for big valued transactions and I could be wrong but from my understanding, people thought of two possible solutions.

Increasing time lock;
Increasing cost for attackers to high enough that is not worthy to do attacks like they will get nothing to do 51% attacks on Bitcoin blockchain for on-chain blocks and transactions.

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.