Hey Matt, Great work on finding this issue, thoroughly testing it against implementations, and on the follow-up you did after reporting this to the various teams.
We all agree that having more people spending time poking at the code to find issues is very beneficial for the project. I hope your work will encourage more people to work on similar research! Protecting p2p networks against DoS vectors is a hard task, and the more eyes on the project, the better. Thanks, Bastien Le lun. 28 août 2023 à 08:46, Antoine Riard <antoine.ri...@gmail.com> a écrit : > Hi Matt, > > > You've definitely done some review for some subset of code, mostly the > anchors code which was added > > not too long ago, but please don't pretend you've reviewed a large > volume of the pull requests in > > LDK, as far as I understand you have several other projects you focus > heavily on, which is great, > > but that's not being a major LDK contributor. > > This is insulting, as I remember very well reviewing some hard parts of > recent ongoing changes such as some API changes for watchtower integration > or the state machine for collaborative transaction construction. Adopting a > pure quantitative measurement of the review contributions is short-sighted > and I think your position forgets with any mature open-source project > review of the hard and sensitive part of the codebase is the bottleneck. > > We're working on a decentralized bitcoin open-source project, there is no > benevolent dictator for life with the legitimacy to qualify who is a major > or "spokesperson" contributor, and who is not. I understand this is your > job to work full-time on LDK, though I don't think there is any contractual > provision in your work contract requesting to play the BDLF. > > If you have a different viewpoint or other professional information to > communicate to the community, thanks. > > > In 2022 and 2023 you: > > * landed a PR removing yourself from the security-reporting list > (#2323, no idea why you're trying > > to speak for the project when you removed yourself!) > > * fixed one bug in the anchors aggregation stuff before it was released > (#1841, thanks!) > > * made some constants public (#1839) > > * increase a constant (#1532) > > * added a trivial double-check of user code (#1531) > > If I remember very well my anchor output patchset was ready to land in the > second-half of 2020, though at that time we didn't have enough qualified > review bandwidth and I spent a hell of a lot of time reviewing other > people's contributions through 2020/2021 to move the project nearer from > production-readiness. That lesson about the anchor output patchset, i.e > coming with meaningful code diff to do _interesting_ things and solve hard > problems as quite rendered me frivolous to show up with big diff, and waste > my coding time (when I can make advance on solving LN-related problems in > Bitcoin Core). > > I think very recently I proposed changes to advance mempool monitoring and > custom script support, though here again it sounds to me we're still > lacking qualified eyes to bring informed technical opinions on the areas > necessitating a lot of context. > > About #2323, the reason of removing myself from the security-reporting > list is related to weak and non-consensual code of conduct you introduced > last year which brings severe vulnerabilities to LDK process w.r.t social > attacks by external actors and risks of long-term shitshow a la Rust > governance, which I raised immediately on the code of conduct PR. I think > you never answered me neither publicly or privately on the lack of > robustness of this code of conduct if we're targeted by psyops from > NK-hacking groups (Sadly, real-world thing in the cryptocurrency world). > > I have no doubt we'll be able to rebuild consensus on our > security-handling / project community process in the future, with calm and > patience. > > > You've also, to my knowledge, never joined the public bi-weekly LDK > development calls, don't join > > the lightning spec meeting, and don't engage in the public discord > discussions where development > > decisions are made. > > Again this is insulting to use the word "never" as I was the original host > of the LDK development meetings on Slack and I think I took the initiative > to launch the LDK review club last year. All those meetings / communication > spaces have public logs to parse interesting to look on and in fine > development decisions are made in a continuous fashion, where the review > and testing process on the repository being the main factor. And I'm pretty > active reviewing things on the lightning spec side at least as much as you. > > > This implies you absolutely don't have a deep understanding of all the > things happening in the > > project, which makes you poorly suited to speak on behalf of the > project. I'm not trying to pass > > judgement on whether you've contributed (you have! thanks for your > contributions!), but only > > suggesting that if you don't contribute regularly enough to have a good > understanding of everything > > going on, speaking on behalf of the project isn't appropriate. > > If you like to judge my "deep understanding" of LDK codebase, you're free > to throw a ldk-sample with the latest v0.0.116 release , throw your money > on it on few channels, send me the node public key and then you'll see > after a while if the funds are still there, otherwise this is cheap talk > and just the subjective appreciation of your mind. > > In reality, I'm still weekly reviewing and hacking on Bitcoin Core's > sensitive parts related to Lightning, and I don't necessarily have the time > to attend *all* the meetings. As a LDK maintainer you should be happy to > have contributors still actively working on Bitcoin Core in the state of > current cross-layer issues, this is not a leisure that all the other LN > implementations can afford! > > > While I know you feel like lightning at large isn't a protocol which > takes security seriously, I > > think you're pretty far off base here. Getting lightning right is > *hard*, as you well know there are > > many, many, many ways it can go wrong. And we, like every other > lightning software project, take > > that seriously, while also trying to ship features to make lightning > broadly useful and usable (two > > things that its historically not really been...because its hard for many > reasons beyond just > > security issues). > > This is not a personal sentiment, though an objectivable engineering facts > that Lightning as a protocol / network is weak, that I did prove few times > in the past for different class of vulnerabilities and that I don't think > you'll argue Lightning is fundamentally weak until package relay / nversion > 3 is deployed and integrated in lightning implementations, and this will > take another couple of years at best. > > I hear you man on the ton ship of features to make lightning and usable, I > think I gave a talk on the liquidity toolchain back in 2019 and the long > road ahead, and I think I'm currently reviewing dual-funding at the > spec-level and in LDK, which is clearly a future people building > real-things on Lightning wish. Come on, I've reviewed almost all of the > hard parts of LDK, I know it's hard though security-first, more and more > end-users have their skin in the game. > > > If you followed LDK (and other lightning) development more closely, I > think you'd have a greater > > appreciation for these things :). > > I think I've been talking in real-life to actual LDK users more recently > than you. If you would listen to Lightning users in an open-minded fashion, > not from your ivory tower of a lightning protocol dev, you'll know how many > people are complaining on the poor usability of the LDK interface, and this > is quite the reason ldk-node was launched, no ? > > > I'm really unsure what you mean here "open-source ethical rules" - is it > your opinion that you > > should speak for a project you don't really follow closely just because > you think the people who do > > work on it a lot aren't doing a good enough job in your opinion? That > seems incredibly strange to me. > > Yes when you're an active contributor to the said project, that you're > spending nights actually reviewing and testing fixes like the ones we > landed for the fake channel DoS vector and you're quite spending a hell of > lof times landing and reviewing other robustness things in the Lightning > ecosystem, you're kinda legitimate to say people do not do a good enough > job. > > This is my current appreciation with 5y of experience than the current LDK > maintenance team adopting a "move fast and break things" attitude w.r.t > landing new features and code changes. I don't know if this is motivated by > some kind of competition for the lowest common technical denominator with > other implementations and fear of losing usage market share). Though yes, I > think the project is taking significant technical debt, especially w.r.t > security, safety, performance and code modularity dimensions. > > I think you're as knowledgeable as myself on the history of the Internet, > I think you're very familiar with the security weakness of the major > Internet protocols like BGP / SMTP and DNS which have somehow led to the > current centralization of mainstream Internet service/usage. In the current > state Lightning is still weak, it will take another 10 years at the current > engineering pace to fix all the major flaws. If we hit TheDAO-like massive > ecosystem hacks leading Lightning users to take refuge behind centralized > "wallet gardens", all the hard work on liquidity management or routing or > state management is quite useless. > > If this is happening, I don't think all the senior Lightning > developers and open-source project manager we'll be able to say we didn't > see this coming. I think Matt Morehouse's security report is actually an > independent underpinning of the meager state of Lightning robustness. This > is where I'm not sure the Lightning community is doing its best in terms of > open-source ethics and safeguard of end-users interests. > > So I'll keep "speaking" for the LDK project whether you're pleased or not, > when I have got my hands dirty on the subject and the current maintenance > team is not doing the job. And all that said, this is okay to have > conflicts in an open-source project and this is somehow positive to grow in > terms of culture, communications or technical philosophy. Thanks for the > hard work you've been doing on LDK for years, though if you aim for more > social recognition you're free to go to work on another open-source > project. Minding the deep respect I have for your sense of dedication and > technical skills, _I don't need you to hack or understand the complex LDK > codebase_. > > If you wish to improve LDK communications, feel free to take > accountability to organize the 1st LDKDev community event (in the image of > CoreDev) in person (maybe SF or LA in the second half of 2024?). I think > someone proposed that idea under "Bitcoin Builder Event" and I think I > still have the publicly shared gdoc from 2021 though this idea has stayed > cheap communication so far. > > In the meantime, there are only 144 blocks in a day (on average) and I > have package relay and mempool to review in Bitcoin Core to improve > Lightning for all, further discussions won't be constructive and I won't > reply further. > > Best, > Antoine > > > > > > > > > > > > > Le dim. 27 août 2023 à 19:00, Matt Corallo <lf-li...@mattcorallo.com> a > écrit : > >> >> >> On 8/26/23 5:03 AM, Antoine Riard wrote: >> > 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 >> >> You've definitely done some review for some subset of code, mostly the >> anchors code which was added >> not too long ago, but please don't pretend you've reviewed a large volume >> of the pull requests in >> LDK, as far as I understand you have several other projects you focus >> heavily on, which is great, >> but that's not being a major LDK contributor. >> >> > and robustness hardening >> > landed during the last two or three years >> >> In 2022 and 2023 you: >> * landed a PR removing yourself from the security-reporting list >> (#2323, no idea why you're trying >> to speak for the project when you removed yourself!) >> * fixed one bug in the anchors aggregation stuff before it was released >> (#1841, thanks!) >> * made some constants public (#1839) >> * increase a constant (#1532) >> * added a trivial double-check of user code (#1531) >> >> You've also, to my knowledge, never joined the public bi-weekly LDK >> development calls, don't join >> the lightning spec meeting, and don't engage in the public discord >> discussions where development >> decisions are made. >> >> This implies you absolutely don't have a deep understanding of all the >> things happening in the >> project, which makes you poorly suited to speak on behalf of the project. >> I'm not trying to pass >> judgement on whether you've contributed (you have! thanks for your >> contributions!), but only >> suggesting that if you don't contribute regularly enough to have a good >> understanding of everything >> going on, speaking on behalf of the project isn't appropriate. >> >> > 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. >> >> While I know you feel like lightning at large isn't a protocol which >> takes security seriously, I >> think you're pretty far off base here. Getting lightning right is *hard*, >> as you well know there are >> many, many, many ways it can go wrong. And we, like every other lightning >> software project, take >> that seriously, while also trying to ship features to make lightning >> broadly useful and usable (two >> things that its historically not really been...because its hard for many >> reasons beyond just >> security issues). >> >> If you followed LDK (and other lightning) development more closely, I >> think you'd have a greater >> appreciation for these things :). >> >> > 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. >> >> I'm really unsure what you mean here "open-source ethical rules" - is it >> your opinion that you >> should speak for a project you don't really follow closely just because >> you think the people who do >> work on it a lot aren't doing a good enough job in your opinion? That >> seems incredibly strange to me. >> >> Matt >> > _______________________________________________ > 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
