Quote from: Primese on Today at 05:54:13 PM

Quote from: Kruw on Today at 01:26:00 AM

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

Quote from: Shinobi

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.