public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Fri, 19 Jul 2024 16:58:02 -0700 (PDT)	[thread overview]
Message-ID: <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com> (raw)
In-Reply-To: <Zpp6U00Mp7Z/bOej@petertodd.org>


[-- Attachment #1.1: Type: text/plain, Size: 15101 bytes --]

Hi Peter,

> A is a low fee-rate transaction with opt-in disabled. When it is 
broadcast, it
> reaches 100% of nodes.
> 
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes 
reject A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.

Okay, I see. Effectively, the attack holds are you're describing as 
transaction A2
will propagate along the `mempoolfullrbf=1` transaction-relay network 
paths. I think
the initial description could have been clearer with this additional 
observation, as
somehow I think there is the low-odd marginal situation where the attacker 
broadcasting
full-node is randomly peered with only transaction-relay `mempoolfullrbf=0` 
neighboring
nodes, and as such the bandwidth waste denial-of-service negligeable.

This is correct there is no concurrent broadcast necessarily involved.

> The % of miners/nodes that accept B isn't particularly relevant; this is 
an
> attack primarily against nodes that have full-RBF disabled (though those 
nodes
> will waste the bandwidth of their full-RBF peers).

Yes I agree with this observation. In a world where a supermajority of 
miners is running
full-rbf as policy settings, I'll let what the corrollorary means in terms 
of transaction-relay
network decentralization to be fully explained by someone else.

> Again, the attack does not depend on a single miner receiving A2. Indeed, 
it
> works fine even if 100% of hash power is mining A2.
> 
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a 
fee-rate
> only slightly higher than A that is still below the minimum economic 
fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is 
a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.

Yes, I think what you're pointing is what makes the attack quite 
interesting as there
is no strict attacker necessity for A2 to be mined at some point in time 
for the attack
effect to play out. Note, see bitcoin core issue #14895 were few years ago 
such mempool
adaptive attacker were pondered about transaction pinnings affecting 
lightning.

> You're not far off. But I believe you are still misunderstanding details, 
as
described above.

See above.

> Correct. Although it's probably simplest to just pick a B that is large 
enough
to max out the mempool limits on its own.

I believe this observation can be still game out more at the advantage of 
the attacker.

> Again, A2 does not need to pay a high enough fee-rate to be economical to 
mine.
> So there are no particular latency requirements between when A, B, and A2 
are
> broadcast.
> 
> All that is necessary for this class of attack is there be at least one 
miner
> willing to mine A2 (or a further double-spend), who rejects A.

Yes, I see more what is interesting with this attack by playing out on 
network
mepool feerate segment asymmetries arising from transaction-relay policy 
divergence.

> This attack is simply a variant of attacks that were publicly disclosed 
months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about 
this
> class of attack by showing they won't even bother to fix the simplest 
possible
> version, even when the fix is trivial.

As I said few months ago, I don't think this is a new class of attacks in 
bitcoin dev
circles conversations about network DoS. To point out more historical 
conversation this
class of attack was pointed out by gmaxwell years ago on the bitcoin core 
pr #16698 few
years ago [0].

[0] https://github.com/bitcoin/bitcoin/pull/16698#issuecomment-571399346

I think rather to accuse people currently maintaining the bitcoin-core sec 
mailing list
of malovencly, it's more constructive to question if this set of people 
still have the
competency and bitcoin security culture to diligently understand and 
address this class
of attacks (and with gmaxwell in its own recent words on another channel 
being far far less
active in bitcoin protocol dev it's not a purely rhetorical question).

In general, there is no necessity to assign to malevolency what can be 
assigned to
genuine incompetence or willful laziness.

> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd 
publish
> if I couldn't get any response. I publicly verified that achow (and 
others) had
> received my email on Jul 10th, with achow promising a response. On Jul 
12th
> rather than replying, Core closed my full-RBF pull-req that fixes this 
issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing 
list,
> and finally got achow and glozow to respond in a perfunctory fashion 
(glozow
> recommended that I open a new full-RBF pull-req). So I published this on 
Jul
> 18th after my replies to achow and glozow didn't get any response. This 
whole
> time no-one has asked me to not publish this attack; asking me to keep 
this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
> 
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from 
technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would 
have
> questioned merging that pull-req. They chose not to do so, proving my 
point
> that none of this has anything to do with a genuine technical concern.

Okay, with more information I think both achow and glozow answers are 
reasonable
in matters of formal responsiveness.

That they pointed out to carry with a public process to fix that category 
of attacks
only give more ground at my hypothesis highlighted above that it can be a 
problem of
security culture knowledge or lack of experience know-how in handling 
"half" / full 
covert fixes.

Sadly, I must say this is matching my historical experience with the 
bitcoin security
mailing list (and I had far more seasoned interlocutors) or the ones of 
other security
issues reporters I'm aware off.

> I was previously on the bitcoin-security mailing list for years, and 
almost
> every disclosed attack has gotten a response within 24 hours, with the 
longest
> about 72 hours (I just skimmed through my archives to double check). 
Failing to
> respond at all is very unusual.

As said in one my previous email, I'm still curious about achow101 
explaining publicly
why you have been kicked-out of the bitcoin-security mailing list, when you 
were certainly
more senior than achow101 in matters of base-layer security issues or even 
hard technical
issues like consensus interactions (e.g bip65). I'll re-iterate my respect 
towards achow101
as a maintainer from years of collaboration, though this is a topic worthy 
of an answer.

Without a public answer under 2 weeks, I'll remove achow101 from among the 
future security
reports recipients I can make about the bitcoin core project, be it a 
report that is codebase-only
or any security issues related to the base layer and affecting all 
full-nodes implementations
or the mining stack.

Under the information shared and from my perspective, achow101 argued 
conduct of playing
for unknown reasons with an adminstrative communication endpoint creates a 
moral hazard
and this would be further unethical for me as a security researcher to 
share sensitive security
information with that bitcoin maintainer.

Best,
Antoine
ots hash: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464

Le vendredi 19 juillet 2024 à 19:27:40 UTC+1, Peter Todd a écrit :

> On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> > Hi Peter,
> > 
> > > I think you need to re-read the attack carefully before we discuss this
> > > further. The % of hash power mining full-rbf does not significantly
> > change the
> > > cost efficiency of the attack as long as the fee-rate of the B
> > transaction(s)
> > > is below the minimum economic fee-rate necessary for miners to mine a
> > > transaction. Above the minimum economic fee-rate, the cost efficiency 
> is
> > an
> > > essentially linear function of % of full-rbf miners.
> > 
> > This is not the % of hash power mining _full-rbf_ I was pointing to, just
> > the indistinct
> > total % of hash power mining.
> > 
> > In my understanding, this is the scenario:
> > - Alice broadcasts small size, low-feerate transaction opt-in disabled A 
> to
> > 99% of the miners+network nodes mempools
> > - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> > Mark, a single miner
> > - Network nodes does not relay transaction A to Mark and vice-versa Mark
> > does not relay transaction A2 to network nodes
>
> Here I think you've misunderstood the attack.
>
> A is a low fee-rate transaction with opt-in disabled. When it is 
> broadcast, it
> reaches 100% of nodes.
>
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes reject 
> A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.
>
> > - Alice broadcasts a child B of transaction A to 99% of the 
> miners+network
> > nodes mempools
>
> The % of miners/nodes that accept B isn't particularly relevant; this is an
> attack primarily against nodes that have full-RBF disabled (though those 
> nodes
> will waste the bandwidth of their full-RBF peers).
>
> > - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> > network bandwidth
>
> Again, the attack does not depend on a single miner receiving A2. Indeed, 
> it
> works fine even if 100% of hash power is mining A2.
>
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a 
> fee-rate
> only slightly higher than A that is still below the minimum economic 
> fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.
>
> > Correct if I'm wrong with this scenario and if it does not match the 
> attack
> > vector you're describing.
>
> You're not far off. But I believe you are still misunderstanding details, 
> as
> described above.
>
> > The child B can be extended with a full chain of useless children within
> > max mempool limits.
>
> Correct. Although it's probably simplest to just pick a B that is large 
> enough
> to max out the mempool limits on its own.
>
> > The attack efficiency (i.e the total vB of bandwidth network waste) is
> > dependent on the delay
> > by which transaction A2 is included in Mark's block template and
> > subsequently mined. Back to
> > my observation, higher are Mark hashrate ressources, less there is 
> latency
> > to let transaction B
> > spontaneously propagate on the network, or for Alice to (re)-broadcast in
> > cycle.
>
> Again, A2 does not need to pay a high enough fee-rate to be economical to 
> mine.
> So there are no particular latency requirements between when A, B, and A2 
> are
> broadcast.
>
> All that is necessary for this class of attack is there be at least one 
> miner
> willing to mine A2 (or a further double-spend), who rejects A.
>
> > All that said, I think my open question to you at the beginning of my
> > answer is still there,
> > i.e how much time has been left between the private report of this issue 
> to
> > the sec mailing
> > list and the public disclosure of your email.
>
> This attack is simply a variant of attacks that were publicly disclosed 
> months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about 
> this
> class of attack by showing they won't even bother to fix the simplest 
> possible
> version, even when the fix is trivial.
>
> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd 
> publish
> if I couldn't get any response. I publicly verified that achow (and 
> others) had
> received my email on Jul 10th, with achow promising a response. On Jul 12th
> rather than replying, Core closed my full-RBF pull-req that fixes this 
> issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing 
> list,
> and finally got achow and glozow to respond in a perfunctory fashion 
> (glozow
> recommended that I open a new full-RBF pull-req). So I published this on 
> Jul
> 18th after my replies to achow and glozow didn't get any response. This 
> whole
> time no-one has asked me to not publish this attack; asking me to keep this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
>
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from 
> technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would 
> have
> questioned merging that pull-req. They chose not to do so, proving my point
> that none of this has anything to do with a genuine technical concern.
>
> I was previously on the bitcoin-security mailing list for years, and almost
> every disclosed attack has gotten a response within 24 hours, with the 
> longest
> about 72 hours (I just skimmed through my archives to double check). 
> Failing to
> respond at all is very unusual.
>
> -- 
> 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/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 17011 bytes --]

  reply	other threads:[~2024-07-20  0:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-18 15:56 [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19  1:05   ` Peter Todd
2024-07-19 13:52     ` Antoine Riard
2024-07-19 14:38       ` Peter Todd
2024-07-19 23:58         ` Antoine Riard [this message]
2024-07-20  0:46           ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21  2:06             ` Antoine Riard
2024-07-21 20:17               ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22  1:59                 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24  0:44                   ` Antoine Riard
2024-08-01  5:57                   ` Garlo Nicon
2024-07-24  0:35                 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56   ` Antoine Riard
2024-07-20  5:57     ` /dev /fd0
2024-07-20 15:08       ` Peter Todd
2024-07-21  2:13         ` Antoine Riard
2024-07-21  6:16         ` /dev /fd0
2024-07-21  2:12       ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10   ` Peter Todd
2024-07-20  6:41 ` David A. Harding
2024-07-20 15:03   ` Peter Todd
2024-07-20 15:30     ` Peter Todd
2024-07-21 15:35     ` David A. Harding
2024-07-21 20:25       ` Peter Todd
2024-07-24  0:38       ` Antoine Riard
2024-07-21  2:10   ` Antoine Riard
2024-07-22 15:10     ` Peter Todd
2024-07-24  0:41       ` Antoine Riard
2024-07-30  4:57     ` David A. Harding
2024-07-30 19:38       ` Peter Todd
2024-08-16  4:45         ` Antoine Riard
2024-08-16  4:20       ` Antoine Riard
2024-07-22 11:45   ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43     ` David A. Harding
2024-07-22 20:06       ` Peter Todd
2024-07-22 22:08         ` David A. Harding
2024-07-23 11:29           ` Peter Todd
2024-07-24  0:42           ` Antoine Riard
2024-07-22 17:13   ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com \
    --to=antoine.riard@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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