* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
@ 2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
0 siblings, 1 reply; 14+ messages in thread
From: David A. Harding @ 2024-03-27 17:18 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-03-27 02:10, Peter Todd wrote:
> On Tue, Mar 26, 2024 at 08:36:45AM -1000, David A. Harding wrote:
>> Could you tell us more about the disclosure process you followed?
>
> see attached.
Do I correctly infer from this that you privately reported the attack on
Thursday around 15:46 UTC, didn't receive any replies in four days
(including a weekend), and published the attack on Monday at 13:21 UTC?
That's a very short timeline to use for going public due to not
receiving a response. I think it's typical to give triage at least 30
days to respond, often while also prompting them additional times for a
response if necessary.
-Dave
--
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/f7fbeb4f58904fc5a24b6fc2d829036c%40dtrt.org.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 17:18 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 David A. Harding
@ 2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50 ` David A. Harding
0 siblings, 1 reply; 14+ messages in thread
From: Peter Todd @ 2024-03-27 18:04 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
On Wed, Mar 27, 2024 at 07:18:08AM -1000, David A. Harding wrote:
> On 2024-03-27 02:10, Peter Todd wrote:
> > On Tue, Mar 26, 2024 at 08:36:45AM -1000, David A. Harding wrote:
> > > Could you tell us more about the disclosure process you followed?
> >
> > see attached.
>
> Do I correctly infer from this that you privately reported the attack on
> Thursday around 15:46 UTC, didn't receive any replies in four days
> (including a weekend), and published the attack on Monday at 13:21 UTC?
>
> That's a very short timeline to use for going public due to not receiving a
> response. I think it's typical to give triage at least 30 days to respond,
> often while also prompting them additional times for a response if
> necessary.
I'm on the bitcoin-security mailing list. Every single plausible issue that has
been raised in the past few years has gotten a response within two days. A few
days is plenty of time to at least respond with a simple "give us more time" if
needed.
Secondly, I was able to verify independently that the relevant people had seen
the email and weren't planning on replying. Which isn't surprising. It's just
another way to perform an obvious, well known, class of attack.
Anyway, I think the lesson to be learned here is I'd have been better off not
disclosing to bitcoin-security first. You're just harassing me here; I highly
suspect you'd have said nothing at all if I hadn't brought up disclosure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZgRfvrYatcpqPNRn%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 18:04 ` Peter Todd
@ 2024-03-27 19:50 ` David A. Harding
2024-03-27 20:30 ` Peter Todd
0 siblings, 1 reply; 14+ messages in thread
From: David A. Harding @ 2024-03-27 19:50 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-03-27 08:04, Peter Todd wrote:
> I was able to verify independently that the relevant people had seen
> the email and weren't planning on replying.
Can you provide detail on this?
> You're just harassing me here; I highly
> suspect you'd have said nothing at all if I hadn't brought up
> disclosure.
I think I would have said something. Any time I'm writing a description
for Optech about an attack that affects existing Bitcoin software and
was responsibly disclosed, I back link to it from a special page [1].
In cases of ambiguity about whether or not an attack was responsibly
disclosed, I investigate.
I'm sorry this feels to you like harassment. To me it feels like
whiplash: I inferred responsible disclosure based on your original text,
learned it might not have been, and now am being told by you that it was
indeed responsible.
-Dave
[1] https://bitcoinops.org/en/topics/responsible-disclosures/
--
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/bbc33ff01e464f8c84a593ac05c5722c%40dtrt.org.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 19:50 ` David A. Harding
@ 2024-03-27 20:30 ` Peter Todd
2024-03-27 22:05 ` Steve Lee
0 siblings, 1 reply; 14+ messages in thread
From: Peter Todd @ 2024-03-27 20:30 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Wed, Mar 27, 2024 at 09:50:20AM -1000, David A. Harding wrote:
> On 2024-03-27 08:04, Peter Todd wrote:
> > I was able to verify independently that the relevant people had seen
> > the email and weren't planning on replying.
>
> Can you provide detail on this?
I'm not going because I don't want anyone else subject to harassment over this.
> > You're just harassing me here; I highly
> > suspect you'd have said nothing at all if I hadn't brought up
> > disclosure.
>
> I think I would have said something. Any time I'm writing a description for
> Optech about an attack that affects existing Bitcoin software and was
> responsibly disclosed, I back link to it from a special page [1]. In cases
> of ambiguity about whether or not an attack was responsibly disclosed, I
> investigate.
>
> I'm sorry this feels to you like harassment. To me it feels like whiplash:
> I inferred responsible disclosure based on your original text, learned it
> might not have been, and now am being told by you that it was indeed
> responsible.
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. Nor have you even tried to argue that my
take on the vulnerability is incorrect: it's just an interesting variation of
well-known attacks that doesn't substantially change the situation.
Anyway, this conversation is just wasting everyones' time. If this actually is
a deal-breaking exploit that must be fixed quickly and quietly - the type of
exploit for which responsible disclosure is necessary - what we should be
talking about is how to fix it. I proposed two different design changes that
mitigates it. One of which fixes other issues too. Antoine Riard also proposed
potential mitigations.
Do you have a useful comment on these proposals?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZgSB6kmLiDG08Yrd%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 20:30 ` Peter Todd
@ 2024-03-27 22:05 ` Steve Lee
2024-03-28 18:34 ` Antoine Riard
0 siblings, 1 reply; 14+ messages in thread
From: Steve Lee @ 2024-03-27 22:05 UTC (permalink / raw)
To: Peter Todd; +Cc: David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
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 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/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 1581 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 22:05 ` Steve Lee
@ 2024-03-28 18:34 ` Antoine Riard
2024-03-28 19:16 ` Peter Todd
0 siblings, 1 reply; 14+ messages in thread
From: Antoine Riard @ 2024-03-28 18:34 UTC (permalink / raw)
To: Steve Lee; +Cc: Peter Todd, David A. Harding, bitcoindev
[-- 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:
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 <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
> 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
> <https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
[-- Attachment #2: Type: text/html, Size: 7160 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-28 18:34 ` Antoine Riard
@ 2024-03-28 19:16 ` Peter Todd
0 siblings, 0 replies; 14+ messages in thread
From: Peter Todd @ 2024-03-28 19:16 UTC (permalink / raw)
To: Antoine Riard; +Cc: Steve Lee, David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]
On Thu, Mar 28, 2024 at 06:34:42PM +0000, Antoine Riard wrote:
> 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."
I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical that we
should even fix it with a fork. SPV validation is very sketchy, and the amount
of work and money required to trigger CVE-2017-12842 is probably as or more
expensive than simply creating fake blocks.
Sergio's RSK Bridge contract being vulnerable to it just indicates it was a
reckless design.
> 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.
To be clear, in this particular case I had specific, insider, knowledge that
the relevant people had in fact seen my report and had already decided to
dismiss it. This isn't a typical case where you're emailing some random company
and don't have any contacts. I personally knew prior to publication that the
relevant people had been given a fair chance to comment, had chosen not to, and
I would likely receive no response at all. Which is really annoying as I have
my own deadlines for (paid) things this research was relevant to: much more
useful to me to get the issue published publicly, so I can get actual comments
from people like yourself, and move forward with my work.
I'm not going to say anything further on how I knew this, because I'm not about
to put up people who have been co-operating with me to the risk of harassment
from people like Harding and others; I'm not very popular right now with many
of the Bitcoin Core people working on the mempool code.
Anyway, I think the lesson learned here is it's probably not worth bothering
with a disclosure process at all for this type of issue. It just created a
bunch of distracting political drama when simply publishing this exploit
variation immediately probably would not have.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZgXCBhL2E6UECXVJ%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 6:27 ` Antoine Riard
@ 2024-03-27 12:54 ` Peter Todd
0 siblings, 0 replies; 14+ messages in thread
From: Peter Todd @ 2024-03-27 12:54 UTC (permalink / raw)
To: Antoine Riard; +Cc: David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]
On Wed, Mar 27, 2024 at 06:27:47AM +0000, Antoine Riard wrote:
> Hi Dave,
>
> > Could you tell us more about the disclosure process you followed? I'm
> > surprised to see it disclosed without any apparent attempt at patching.
> > I'm especially concerned given your past history of publicly revealing
> > vulnerabilities before they could be quietly patched[1] and the conflict
> > of interest of you using this disclosure to advocate for a policy change
> > you are championing.
>
> In defense of Peter, I don't think there is a low-hanging fruit that could
> have
> been landed easily in Bitcoin Core. The most obvious ones could have been
> a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule
> `max_replacement_bandwidth`
> or c) a new absolute-fee based penalty on bandwidth replacement cost.
To be clear, I _did_ disclose the issue on bitcoin-security and no-one had any
objections to disclosing it publicly.
> All hard to integrate in a covert fashion without attracting some attention
> from the
> community, which would certainly ask why we're changing the marginal
> bandwidth cost.
> Potentially, impacting unfavorably some use-cases.
>
> Certainly, Peter's report could have integrated a disclosure timeline at the
> example of CVE-2018-17144 [0], which I can recommend to anyone to follow
> doing
> security research or servicing as a security point of contact in our field.
Since this attack is just a relatively minor extension of existing, publicly
disclosed, attacks, I don't think there was any need for formal disclosure
timelines. It's interesting that the attack exists; it does not substantially
change the status quo.
I don't believe the other attacks in this attack class are even possible to
fix. We just have to live with the fact that a degree of free relay is always
going to be possible.
> I don't see the conflict of interest in the present disclosure ? It is
> public information
> that Peter is championing RBFR [1]. I'm not aware of any private interest
> unfavorably
> influencing Peter's behavior in the conduct of this security issue
> disclosure.
Well, there is a conflict of interest in trying to keep this issue under wraps:
Replace-By-Fee-Rate benefits from public discussion of the fact that many
different free-relay attacks are possible. The arguments against RBFR mainly
hinge on the idea that free-relay is preventable.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZgQXHpraCWeEyDKe%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-26 18:36 ` David A. Harding
@ 2024-03-27 6:27 ` Antoine Riard
2024-03-27 12:54 ` Peter Todd
0 siblings, 1 reply; 14+ messages in thread
From: Antoine Riard @ 2024-03-27 6:27 UTC (permalink / raw)
To: David A. Harding; +Cc: Peter Todd, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4387 bytes --]
Hi Dave,
> Could you tell us more about the disclosure process you followed? I'm
> surprised to see it disclosed without any apparent attempt at patching.
> I'm especially concerned given your past history of publicly revealing
> vulnerabilities before they could be quietly patched[1] and the conflict
> of interest of you using this disclosure to advocate for a policy change
> you are championing.
In defense of Peter, I don't think there is a low-hanging fruit that could
have
been landed easily in Bitcoin Core. The most obvious ones could have been
a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule
`max_replacement_bandwidth`
or c) a new absolute-fee based penalty on bandwidth replacement cost.
All hard to integrate in a covert fashion without attracting some attention
from the
community, which would certainly ask why we're changing the marginal
bandwidth cost.
Potentially, impacting unfavorably some use-cases.
Certainly, Peter's report could have integrated a disclosure timeline at the
example of CVE-2018-17144 [0], which I can recommend to anyone to follow
doing
security research or servicing as a security point of contact in our field.
I don't see the conflict of interest in the present disclosure ? It is
public information
that Peter is championing RBFR [1]. I'm not aware of any private interest
unfavorably
influencing Peter's behavior in the conduct of this security issue
disclosure.
One of the established principles in infosec, it's up to software vendors
to explain
why their softwares is broken or why they are "lazy" fixing issues.
Assuming sufficient
technical proof has been initially communicated by the reporter.
If you're dissatisfied by Peter's conduct in the handling of this
disclosure, you're welcome
to author vulnerability reports or assume the role of coordinating patching
responses yourself
more often. Assuming you can be reasonably trusted here.
Finally, in matters of ethics, talking as an external observer can be cheap
sometimes and it is
best to "lead-by-example", imho.
Best,
Antoine
[0] https://bitcoincore.org/en/2018/09/20/notice/
[1] https://petertodd.org/2024/one-shot-replace-by-fee-rate
Le mar. 26 mars 2024 à 18:38, David A. Harding <dave@dtrt•org> a écrit :
> On 2024-03-18 03:21, Peter Todd wrote:
> > [...] the existence of this attack is an argument in favor of
> > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the
> > fact
> > that Bitcoin Core's existing rules *also* allow for free-relay in this
> > form
> > makes the difference inconsequential.
> >
> > # Disclosure
> >
> > This issue was disclosed to bitcoin-security first. I received no
> > objections to
> > making it public. All free-relay attacks are mitigated by the
> > requirement to at
> > least have sufficient funds available to allocate to fees, even if the
> > funds
> > might not actually be spent.
>
> Could you tell us more about the disclosure process you followed? I'm
> surprised to see it disclosed without any apparent attempt at patching.
> I'm especially concerned given your past history of publicly revealing
> vulnerabilities before they could be quietly patched[1] and the conflict
> of interest of you using this disclosure to advocate for a policy change
> you are championing.
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016100.html
>
> --
> 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/012f89763cc336cd91eec13dccefc921%40dtrt.org
> .
>
--
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%2BHNiwie1RNJOi9WJs-F2%3DYSvFdwCDfdNDuTdUuSf_kTBg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6425 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-18 13:21 Peter Todd
2024-03-19 12:37 ` Nagaev Boris
@ 2024-03-26 18:36 ` David A. Harding
2024-03-27 6:27 ` Antoine Riard
1 sibling, 1 reply; 14+ messages in thread
From: David A. Harding @ 2024-03-26 18:36 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-03-18 03:21, Peter Todd wrote:
> [...] the existence of this attack is an argument in favor of
> replace-by-fee-rate. While RBFR introduces a degree of free-relay, the
> fact
> that Bitcoin Core's existing rules *also* allow for free-relay in this
> form
> makes the difference inconsequential.
>
> # Disclosure
>
> This issue was disclosed to bitcoin-security first. I received no
> objections to
> making it public. All free-relay attacks are mitigated by the
> requirement to at
> least have sufficient funds available to allocate to fees, even if the
> funds
> might not actually be spent.
Could you tell us more about the disclosure process you followed? I'm
surprised to see it disclosed without any apparent attempt at patching.
I'm especially concerned given your past history of publicly revealing
vulnerabilities before they could be quietly patched[1] and the conflict
of interest of you using this disclosure to advocate for a policy change
you are championing.
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016100.html
--
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/012f89763cc336cd91eec13dccefc921%40dtrt.org.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-19 13:46 ` Peter Todd
@ 2024-03-23 0:29 ` Nagaev Boris
0 siblings, 0 replies; 14+ messages in thread
From: Nagaev Boris @ 2024-03-23 0:29 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On Tue, Mar 19, 2024 at 10:46 AM Peter Todd <pete@petertodd•org> wrote:
>
> On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote:
> > Hi Peter,
> >
> > On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote:
> > > Rule #6 creates a path dependency: the order in which replacement transactions
> > > are received determines which transactions are ultimately accepted.
> >
> > I'd like to share my thoughts regarding RBFR rules and propose something.
> >
> > The proposed RBFR rule is also path-dependent. Two transactions can
> > conflict with each other, but their fee rates can be too close for one
> > of them to eliminate the other from nodes' mempools. The first
> > transaction a node sees is kept in its mempool.
>
> It's not really fair to say that "the proposed RBFR rule is also
> path-dependent". What you're describing is a property of Bitcoin Core's mempool
> in general, for all transaction acceptance rules. We've *always* had the
> property that two essentially identical transactions, differing only in a
> trivial way, will be accepted on a first seen basis. Achieving consensus
> requires bandwidth, and since you can generate an essentially infinite number
> of almost identical transactions, you'll always be able to find cases with path
> dependency.
>
> > Is it possible to have a rule that is completely path-independent? The
> > eviction rules are path-independent iff, for each pair of conflicting
> > transactions A and B, it is always known which of them should be
> > preferred over the other, and this relation is transitive. Having such
> > a property would be very beneficial in preventing any attacks on the
> > mempool. This property of the mempool can also be seen as the eventual
> > consistency of all the mempools of the nodes. A good property, isn't
> > it?
>
> I'd suggest that you should argue concretely *why* this is a good property. The
> RBF Rule #6 issue isn't strong evidence, as it's only related to a specific
> type of meaningful path dependency, where fees/size differ meaningfully. You're
> talking about all forms of path dependency, including trivial differences where
> fees/size are the same and only a txid differs due to a trivial change.
I rethought it and I think I'm wrong. The proposed solution of
delaying and skipping won't fix the replacement attack, because the
preimage could be a skipped transaction, so the attacked node could
miss it.
For my proposal to work it should be changed to guarantee that any
transaction is spread to all the nodes eventually, i.e. no skipping.
This means broadcasting all transactions eventually. But this is
impossible to implement without creating DoS vectors either in
bandwidth or in memory (the later - in case transactions to be
broadcasted are accumulated in a buffer by a node).
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt5kHtRj%2BypoxGKZUD1-NdSnbC9m%3DzwWnjVSTcROp7aLow%40mail.gmail.com.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-19 12:37 ` Nagaev Boris
@ 2024-03-19 13:46 ` Peter Todd
2024-03-23 0:29 ` Nagaev Boris
0 siblings, 1 reply; 14+ messages in thread
From: Peter Todd @ 2024-03-19 13:46 UTC (permalink / raw)
To: Nagaev Boris; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5313 bytes --]
On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote:
> Hi Peter,
>
> On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote:
> > Rule #6 creates a path dependency: the order in which replacement transactions
> > are received determines which transactions are ultimately accepted.
>
> I'd like to share my thoughts regarding RBFR rules and propose something.
>
> The proposed RBFR rule is also path-dependent. Two transactions can
> conflict with each other, but their fee rates can be too close for one
> of them to eliminate the other from nodes' mempools. The first
> transaction a node sees is kept in its mempool.
It's not really fair to say that "the proposed RBFR rule is also
path-dependent". What you're describing is a property of Bitcoin Core's mempool
in general, for all transaction acceptance rules. We've *always* had the
property that two essentially identical transactions, differing only in a
trivial way, will be accepted on a first seen basis. Achieving consensus
requires bandwidth, and since you can generate an essentially infinite number
of almost identical transactions, you'll always be able to find cases with path
dependency.
> Is it possible to have a rule that is completely path-independent? The
> eviction rules are path-independent iff, for each pair of conflicting
> transactions A and B, it is always known which of them should be
> preferred over the other, and this relation is transitive. Having such
> a property would be very beneficial in preventing any attacks on the
> mempool. This property of the mempool can also be seen as the eventual
> consistency of all the mempools of the nodes. A good property, isn't
> it?
I'd suggest that you should argue concretely *why* this is a good property. The
RBF Rule #6 issue isn't strong evidence, as it's only related to a specific
type of meaningful path dependency, where fees/size differ meaningfully. You're
talking about all forms of path dependency, including trivial differences where
fees/size are the same and only a txid differs due to a trivial change.
> How can we design such a rule system?
>
> 1. It must align with miners' incentives; otherwise, it simply won't work.
> 2. And it must not open the door for DoS attacks on the mempool.
>
> The naive approach satisfying the first requirement is a simple rule
> saying "the higher the fee rate, the more preferential is the
> transaction." However it does not specify what to do with two
> transactions of the same fee rate and also doesn't prevent DoS
> attacks. The former is easy to fix, e.g. preferring the transaction
> with lower txid. (Must be formally proven though.) Let's discuss the
> latter, which is a stumbling stone here.
>
> Traditionally, the way of preventing DoS was to reject some
> transactions and to stop their broadcasting at this node. What about
> deprioritizing them instead? Make two priority queues of transactions
> in the node: (1) to process incoming transactions and (2) to
> broadcast. When a transaction is double-spent, it is deprioritized in
> both queues. If an attacker sends many double-spending transactions to
> DoS the mempool, not all of them are broadcast further because by the
> time a transaction is ready to be broadcast, its newer version has
> already evicted it; the first one is not yet broadcasted. So a node
> broadcasts fewer transactions than it receives, which reduces the DoS
> effect. And still, the whole system is eventually consistent; just
> spammers get their transactions spread slower.
>
> What are your thoughts on this scheme?
So first of all, I'll point out that because you can brute force txid
variations, if the rule is lowest txid wins, it wouldn't be hard to do a bit
of brute forcing to get, say, 2^32 = 4 billion different variations. For
practical purposes, that's basically infinite bandwidth.
OTOH, suppose the rule is that the txid with the most leading zeros wins. This
fixes the infinite bandwidth problem, as it's a clear PoW with something like
48 possible total replacements at most (assuming a reasonable amount of total
PoW). But the mempool consensus problem remains unfixed, as there's essentially
infinite variations possible with the same number of leading zeros.
Bitcoin doesn't have this issue because it has a minimum PoW, set by the
difficulty algorithm. But we can't ask that of transactions in general. So I
think either way we've failed to actually achieve consensus over trivial
variations.
More broadly, I like the idea of using a bandwidth constrained channel for
doing replacements where there are meaningful, but small, differences in the
size and/or fees paid. But I think we should persue the idea on the basis that
it makes economic sense. Not that it'll prevent mempools from being out of
consensus.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/ZfmXNiscjatFOOCX%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-18 13:21 Peter Todd
@ 2024-03-19 12:37 ` Nagaev Boris
2024-03-19 13:46 ` Peter Todd
2024-03-26 18:36 ` David A. Harding
1 sibling, 1 reply; 14+ messages in thread
From: Nagaev Boris @ 2024-03-19 12:37 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
Hi Peter,
On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote:
> Rule #6 creates a path dependency: the order in which replacement transactions
> are received determines which transactions are ultimately accepted.
I'd like to share my thoughts regarding RBFR rules and propose something.
The proposed RBFR rule is also path-dependent. Two transactions can
conflict with each other, but their fee rates can be too close for one
of them to eliminate the other from nodes' mempools. The first
transaction a node sees is kept in its mempool.
Is it possible to have a rule that is completely path-independent? The
eviction rules are path-independent iff, for each pair of conflicting
transactions A and B, it is always known which of them should be
preferred over the other, and this relation is transitive. Having such
a property would be very beneficial in preventing any attacks on the
mempool. This property of the mempool can also be seen as the eventual
consistency of all the mempools of the nodes. A good property, isn't
it?
How can we design such a rule system?
1. It must align with miners' incentives; otherwise, it simply won't work.
2. And it must not open the door for DoS attacks on the mempool.
The naive approach satisfying the first requirement is a simple rule
saying "the higher the fee rate, the more preferential is the
transaction." However it does not specify what to do with two
transactions of the same fee rate and also doesn't prevent DoS
attacks. The former is easy to fix, e.g. preferring the transaction
with lower txid. (Must be formally proven though.) Let's discuss the
latter, which is a stumbling stone here.
Traditionally, the way of preventing DoS was to reject some
transactions and to stop their broadcasting at this node. What about
deprioritizing them instead? Make two priority queues of transactions
in the node: (1) to process incoming transactions and (2) to
broadcast. When a transaction is double-spent, it is deprioritized in
both queues. If an attacker sends many double-spending transactions to
DoS the mempool, not all of them are broadcast further because by the
time a transaction is ready to be broadcast, its newer version has
already evicted it; the first one is not yet broadcasted. So a node
broadcasts fewer transactions than it receives, which reduces the DoS
effect. And still, the whole system is eventually consistent; just
spammers get their transactions spread slower.
What are your thoughts on this scheme?
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt7BE866DJGQ9EqA%2BDroEkDH%2B4U_72-RpCUfyrLHmtnZ1Q%40mail.gmail.com.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
@ 2024-03-18 13:21 Peter Todd
2024-03-19 12:37 ` Nagaev Boris
2024-03-26 18:36 ` David A. Harding
0 siblings, 2 replies; 14+ messages in thread
From: Peter Todd @ 2024-03-18 13:21 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5513 bytes --]
RBF Rule #6 requires that a replacement transaction have a fee-rate higher than
the fee-rate of all conflicting transactions. This rule aligns economic
incentives, as in most circumstances miners earn more money by mining a higher
fee-rate transaction than a lower fee-rate transaction, even if the absolute
fee paid by the replacement is more.
While RBF Rule #6 was implemented as part of my original Full-RBF opt-in
pull-req¹, it was mistakenly left out of BIP-125, which was written later by
Harding. Thus it's often forgotten in analysis of RBF.
Rule #6 creates a path dependency: the order in which replacement transactions
are received determines which transactions are ultimately accepted. This
creates an opportunity for free-relay, as follows:
1. Create two transactions, A and B, where A is a large, low fee-rate, high
absolute fee, transaction, and B is a small, high fee-rate, low absolute fee
transaction.
2. Broadcast A and B to different nodes simultaneously.
3. Nodes that receive A first will not replace A with B, because B pays a lower
fee, violating RBF Rule #3. Notes that receive B first, will not replace B with
A, because A has a lower fee-rate, violating RBF Rule #6.
4. Create A_1, a transaction with the same (large) size as A, but paying a
slightly higher fee (and thus fee-rate). Nodes that received A first will
replace A with A_1, consuming bandwidth. These nodes will also broadcast A_1 to
peers who have B, consuming their bandwidth even though they reject A_1.
5. Repeat until A_n has a fee-rate high enough to have a non-trivial risk of
being mined. Or B is mined, invalidating all A_n.
The marginal cost to an attacker who was planning on broadcasting B anyway is
fairly small, as provided that sufficiently small fee-rates are chosen for A_n,
the probability of A_n being mined is low. The attack does of course require
capital, as the attacker needs to have UTXO's of sufficient size for A_n.
The attack is most effective in cases where fee-rates have a significant slope
to them, with the minimum relay fee being small compared to the competitive fee
to get into the next block. The larger the mempool size limit, the more
effective the attack tends to be. Similarly, the attack is more effective with
a larger size difference between A and B. Finally, the attack is more effective
with a smaller minimum incremental relay fee, as more individual versions of
the transaction can be broadcast for a given fee-delta range.
Of course, this attack can be parallelized, with many non-conflicting A_n
chains at once. Depending on P2P topology, maximum bandwidth may be consumable
by broadcasting multiple _conflicting_ A's to different nodes at once², a
fairly obvious attack that I (and probably others) have already disclosed.
# Mitigations
Replace-by-Fee-Rate mitigates the attack, by limiting the possible range of
fee-rate delta. For example, in Libre Relay, which does replace-by-fee-rate at
a fee-rate ratio of >= 2x, if A starts at 3sat/VB, the attacker can only do 2
cycles of the attack as a B >= 6sat/VB will simply replace A.
The attack itself is arguably an economic exploit: *because* Bitcoin Core
doesn't yet implement replace-by-fee-rate, nodes who accepted A first, are
wasting their bandwidth relaying variations on A that are clearly less
desirable to miners than B. An economically rational miner would just mine B
right now, and the fact that _other_ economically rational miners would mine B
just strengthens the case for mining B now. Indeed, real-world measurements of
replace-by-fee-rate have found that (most likely) due to mempool
inconsistencies, roughly half or more³ of RBFR replacements are mined already.
Requiring replacements to increase the fee-rate by a certain ratio would also
mitigate the attack. However doing so would break a lot of wallet software that
bumps fees by values equal or close to the minimum relay fee.
# Related Attacks
Rule #6 is just one of many ways to achieve the same effect: getting a miner to
invalidate a set of large transactions, wasting bandwidth. For example, miners
who accept payment for guaranteeing that a specific transaction gets mined also
make this kind of attack possible.
# Discussion
Ironically, the existence of this attack is an argument in favor of
replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fact
that Bitcoin Core's existing rules *also* allow for free-relay in this form
makes the difference inconsequential.
# Disclosure
This issue was disclosed to bitcoin-security first. I received no objections to
making it public. All free-relay attacks are mitigated by the requirement to at
least have sufficient funds available to allocate to fees, even if the funds
might not actually be spent.
# References
1) https://github.com/bitcoin/bitcoin/pull/6871
2) https://petertodd.org/2024/one-shot-replace-by-fee-rate#the-status-quo
3) https://petertodd.org/2024/replace-by-fee-rate-success-rate
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/Zfg/6IZyA/iInyMx%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-03-28 19:29 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-27 17:18 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox