rich1.0t4es5ter5 wrotet4es5ter5 (npub1rx…ana9d)https://yabu.me/npub1rxdgaa26crjvsrxsxn90lcmsyujz2k37f5d2a5fty3w9z4hzxznqvana9dnjumphttps://yabu.meI have decide to stop with my lightning node.
Too risky.
Also got another force close of WalletOfSatoshi
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html
https://stacker.news/items/288995
I think this new class of replacement cycling attacks puts lightning in a
very perilous position, where only a sustainable fix can happen at the
base-layer, e.g adding a memory-intensive history of all-seen transactions
or some consensus upgrade. Deployed mitigations are worth something in face
of simple attacks, though I don't think they're stopping advanced attackers
as said in the first full disclosure mail.
Those types of changes are the ones necessitating the utmost transparency
and buy-in of the community as a whole, as we're altering the full-nodes
processing requirements or the security architecture of the decentralized
bitcoin ecosystem in its integrality.
On the other hand fully explaining why such changes would be warranted for
the sake of lightning and for designing them well, we might need to lay out
in complete state practical and critical attacks on a ~5 355 public BTC
ecosystem.
Hard dilemma.
There might be a lesson in terms of bitcoin protocol deployment, we might
have to get them right at first try. Little second chance to fix them in
flight.
I'll be silent on those issues on public mailing lists until the week of
the 30 oct. Enough material has been published and other experts are
available. Then I'll be back focusing more on bitcoin core.
Best,
Antoine