public inbox for
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail•com>
To: Steve Lee <steven.j.lee@gmail•com>
Cc: Peter Todd <pete@petertodd•org>,
	"David A. Harding" <dave@dtrt•org>,
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
Date: Thu, 28 Mar 2024 18:34:42 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 5336 bytes --]

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:

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

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:

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.


[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 <steven.j.lee@gmail•com> a écrit :

> On Wed, Mar 27, 2024 at 2:56 PM Peter Todd <pete@petertodd•org> 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
> 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
> <>
> .

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

[-- Attachment #2: Type: text/html, Size: 7160 bytes --]

  reply	other threads:[~2024-03-28 18:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50   ` David A. Harding
2024-03-27 20:30     ` Peter Todd
2024-03-27 22:05       ` Steve Lee
2024-03-28 18:34         ` Antoine Riard [this message]
2024-03-28 19:16           ` Peter Todd
  -- strict thread matches above, loose matches on Subject: below --
2024-03-18 13:21 Peter Todd
2024-03-19 12:37 ` Nagaev Boris
2024-03-19 13:46   ` Peter Todd
2024-03-23  0:29     ` Nagaev Boris
2024-03-26 18:36 ` David A. Harding
2024-03-27  6:27   ` Antoine Riard
2024-03-27 12:54     ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \
    --to=antoine.riard@gmail$(echo .)com \ \
    --cc=dave@dtrt$(echo .)org \
    --cc=pete@petertodd$(echo .)org \
    --cc=steven.j.lee@gmail$(echo .)com \
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox