Hi Steve, > He literally cites a reference to an example. About CVE-2017-12842, the report of Sergio Demian Lerner available here gives more information on the reporting process of the vulnerability: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ I'll attract attention on the following words of Sergio himself: "and as I said in the first paragraph, the weakness was already known by some developers. But I still don't understand (1) why so many people knew about it but underestimated it badly, (2) why there was no attempt to fix it." Sadly, from my experience reporting weaknesses or reviewing security patches in Bitcoin Core, senior developers in this field are still aware of more vulnerabilities than they usually have time to fix them. Additionally, sometimes "ambiguous" patches are deliberately done where a lightweight weakness is fixed and argued in public as such, when in reality more severe issues are hardened under the hood. In the present case making non-standard 64 bytes transactions without witness in Bitcoin Core 16.0 added a belt-and-suspender in face of block-malleability validation issues that could split the network _and_ it leveled up the bar for double-spending SPV clients. That latest exploitation scenario was the one which was early disclosed by Peter in June 2018. Coming back to the present "free-relay" bandwidth wasting class of attack disclosure, I effectively myself think a 4-days delay was a bit short for a full disclosure. Comparing to CVE-2021-31876 (core's lack of inheritance signaling), full disclosure report is available here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html The initial report was made 2021-03-19. We didn't go the route of landing a covert patch as it was appreciated that potential DoS risks outweighs the safety of non-anchors exposed LN channels. Weakness report was made available the 2021-05-06 after noticing maintainers of most-likely exposed Bitcoin softwares, so a delay of 50-days. As a reminder, in the full disclosure report I myself champion some changes in the BOLT protocol such as dynamic upgrades that would make handling this kind of security issues easier [0]. I believe in the present "free-relay" bandwidth wasting, letting a minimal 2-weeks delay would have been more reasonable. Security list members might be in flight travels or at conferences, or under other operational constraints and domain experts in the area of transaction-relay might not be available to give full-fledged answers. Even if you have private contacts of someone, don't rush them to get an answer when it can be midnight in their time zones and they're recovering from jet lags. On the other hand, if you don't receive a satisfying answer as a security finding reporter after 2 weeks, or an acknowledgement of email reporting reception after ~72 hours from vendors, I still think you're free to move ahead with a full disclosure. Sadly, I had "bad faith" vendor cases in my career as a security researcher in considerations of ethical infosec rules. Best, Antoine [0] By the way the pinning vector exposed in CVE-2021-31876 still affects LDK channels as the commit beef584c `negotiate_anchors_zero_fee_htlc_tx` is false by default. And this is not fixed by v3 without avoiding all nversion=2 by an on-chain confirmation to be replayed (L792, src/validation.cpp - commit d1e9a02). I"ll be polite and not ask what LDK maintainers are doing with their time. Le mer. 27 mars 2024 à 22:14, Steve Lee a écrit : > > > On Wed, Mar 27, 2024 at 2:56 PM Peter Todd wrote: > >> >> I'm not the only person who thinks this looks like harassment. The fact >> is you >> started this conversation with: "I'm especially concerned given your past >> history of publicly revealing vulnerabilities before they could be quietly >> patched and the conflict of interest of you using this disclosure to >> advocate >> for a policy change you are championing." >> >> You haven't substantiated any of this. > > > He literally cites a reference to an example. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com > > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BEK26%3DE6U9OdY%2Bc9LVQnGtb-f5zzKt5RTwBoHpr_SSxcA%40mail.gmail.com.