Hi Matt, > While you were aware of these fixes at the time, I'd appreciate it if you, someone who hasn't spent > much time contributing to LDK over the past two or three years, stop trying to speak on behalf of > the LDK project.
While this statement is blatantly false and disregards all the review and robustness hardening landed during the last two or three years, I would appreciate it from you in the conduct of your maintenance janitorial role to have more regard for the LDK users funds security rather than a "move fast and break things" attitude. As such, and with in mind all open-source ethical rules, I'll keep speaking on the behalf of the LDK project when I see fit, whether you're pleased or not. Best, Antoine Le ven. 25 août 2023 à 20:30, Matt Corallo <lf-li...@mattcorallo.com> a écrit : > While you were aware of these fixes at the time, I'd appreciate it if you, > someone who hasn't spent > much time contributing to LDK over the past two or three years, stop > trying to speak on behalf of > the LDK project. > > Thanks, > Matt > > On 8/24/23 4:33 PM, Antoine Riard wrote: > > Hi Matt, > > > > Thanks for the great work here. > > > > Confirming the v0.0.114 release number for the LDK "fake" lightning > channels mitigations. > > > > From the LDK-side, the vulnerability didn't come as novel knowledge, we > have thought of potential > > DoS issues in peer state machine handling (e.g [0]) a long time ago and > our long-term design > > philosophy has always been to privilege watchtower and process > separation as a defense in-depth > > mitigation (e.g see our glossary about "monitor replica" [1]). All those > hardening architectures are > > not implemented yet as part of the "vanilla" LDK (we're a library > after), though it's consistent > > with the answer we made privately during your disclosure. > > > > About the lessons, a few remarks. > > > > "Use watchtowers": note there is difference between watchtower only > encompassing revoked state > > punishment and "monitor replica' encompassing second-stage HTLC. For > that type of DoS issues, you > > wish to have the second deployed. > > > > "Multiple process": note your Lightning node multi-process should be > free of "deadlock" and other > > processing contaminating bugs, i.e the chain monitoring and reaction > logic should maintain > > liveliness even if the off-chain state machine coordinator (let's say > `ChannelManager`) got DoS / > > crashed, the chain monitoring should be able to detect revoked states > and react finally. > > > > "More security auditing needed": I can only share the opinion that > security and robustness has not > > been the top priorities of the lightning implementations, for a very > long time, I think > > implementations have been more focus on spec features parity to maintain > a usage market share, > > rather thinking about the long-term network sustainability and safety of > end-user funds. For the > > more senior Lightning devs, those issues won’t come as strong surprise, > I think some things like > > package relay rank higher on folks priorities to mitigate publicly known > and more serious security > > issues [2]. > > > > Looking forward to more security auditing of the Lightning Network. > > > > Cheers, > > Antoine > > > > [0] https://github.com/lightningdevkit/rust-lightning/issues/383 > > <https://github.com/lightningdevkit/rust-lightning/issues/383> and > > https://github.com/lightningdevkit/rust-lightning/issues/59 > > <https://github.com/lightningdevkit/rust-lightning/issues/59> > > [1] > https://github.com/lightningdevkit/rust-lightning/blob/main/GLOSSARY.md#monitor-replicas > > < > https://github.com/lightningdevkit/rust-lightning/blob/main/GLOSSARY.md#monitor-replicas > > > > [2] https://github.com/bitcoin/bips/pull/1382 < > https://github.com/bitcoin/bips/pull/1382> > > > > Le jeu. 24 août 2023 à 01:36, Matt Morehouse <mattmoreho...@gmail.com > > <mailto:mattmoreho...@gmail.com>> a écrit : > > > > Hi list, > > > > Last year a DoS vector was discovered to affect all node > > implementations, where an attacker could open large numbers of fake > > channels to the victim and never publish them on-chain, causing the > > victim to consume excessive resources. > > > > Defenses against the DoS have been shipped in the following releases: > > - CLN 23.02 [1] > > - eclair 0.9.0 [2] > > - LDK 0.0.114 [3] > > - LND 0.16.0 [4] > > > > If you are running node software older than this, your funds may be > at > > risk! Update to at least the above versions to help protect your > > node. > > > > More details about the DoS vector are available at > > https://morehouse.github.io/lightning/fake-channel-dos > > <https://morehouse.github.io/lightning/fake-channel-dos>. > > > > - Matt > > > > [1] https://github.com/ElementsProject/lightning/releases/tag/v23.02 > > <https://github.com/ElementsProject/lightning/releases/tag/v23.02> > > [2] https://github.com/ACINQ/eclair/releases/tag/v0.9.0 > > <https://github.com/ACINQ/eclair/releases/tag/v0.9.0> > > [3] > https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114 > > < > https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.114> > > [4] > https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta > > <https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta> > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org <mailto: > Lightning-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev> > > > > > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
