path: root/db/ca3b12c9449cb10d9a88ffc0e8010ba01c12ab

Delivery-date: Fri, 19 Jul 2024 17:01:22 -0700
Received: from mail-yw1-f191.google.com ([209.85.128.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBSP45O2AMGQELKWHE6Q@googlegroups.com>)
	id 1sUxXM-0004un-Mk
	for bitcoindev@gnusha.org; Fri, 19 Jul 2024 17:01:22 -0700
Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-664c185a606sf68160487b3.2
        for <bitcoindev@gnusha.org>; Fri, 19 Jul 2024 17:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721433674; x=1722038474; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=;
        b=XGoYnwTCRmv9/FVq9Nv7E7vtKfWbK+PCrdEPd1RYhV3DfOCVZAkhy2xBtj4y7KvSXk
         6KG3vrYXbB7fx+ZAQFCg+kujGRM5NaWXvlkRFjIf/cCh7//Kh4gzDViD+dZHZu6ranVP
         v7sKRuXPM/TyS/N6lXNDoImYxvnJXLaSXztCIUDfEL8qIoE0o/cQOmsubCjVxo4e383v
         bwlKPfZGPqpZ2kgjA6xrpdbiQFU8mwYmlUSzx6lXgsKWVpz1uRx2gtT3zZj9ACMW8s6J
         cGAiipYN36adWS8uOytglD8Zl1CTeA5YCXXrwXTuwEvxB+WYoreAIJgURasuC2C8fQY+
         KX5w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1721433674; x=1722038474; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=;
        b=QYeNnRigRSb04AJduEvC1CC1bCyfeh1lW4hxIEzM6XLRPLCEGQbW7mX+fxmxwvkpjO
         vZLlQo74uPnXydAGkGuIJuAhU5UbFdpOYXDZhh/rdubap0MRZkcb2LQxUSuI1qC/D9nP
         Lifu+Ffd00SifX/ogEy0195/jJgma1ad8Dflf2H2nXldAjeUgiZab3A2iSXQuSLOwBwJ
         5sts/NgE46ie/YOq/CfP4VPzH8yBJ+thHM3ERo6P7oxKuZR5Y0os/uL8521ihmY6Smx3
         p2T5zlOEfUKQhpVzVNRkZyqbisYbZzpk+DkoUSaUIl1WdNOp0TjW3yoQCQjgxoCMgeRK
         jGeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721433674; x=1722038474;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=;
        b=EfL9MvyIXGWK3bV8+tkG1IjI1icnYpEE8GwzrH3roWITqmwwJT46Uvx16xCPCVPgmC
         P90ru4x7p7OzzSNZegZfAfZumhHtQXReL1ymMlCD+zNvNywdTUKuXGcP9NSb58ysxm/n
         ndOcyn7AmKskgACHmY/VLNq9GMwfmQAIWuUNzexc9IFZYto/Xdum1ohU3x3qfLjkJGCL
         OKvkxD8NSaRzkBXrgBQJTS6NURuOy/COc3T+ljouJq5Uq+sEwJwmyehonHn/Di3K3zhN
         dT1Bp/nAA2f/kncJBFkYUmMFfBs1liQv3nQB1QtsmUfn6Gt51QOzj5Hzuoz5pCRd5/mr
         jk1w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUf/wPLsVDmiJTw+0nAhXgnzK6ydtdTVjT3L9pU6UO92WnE1fAG0gMTgxz9jelFim1QkeI8JnhZRo55RbkaKFiaruhOHOE=
X-Gm-Message-State: AOJu0YwKGCz2ucrkzf0TYbsU0Yvjd7M3yUu0zpeKwXZ3nQNRdlxrBOho
	Pz2NFQHguVS3HKsM+tO6EOCKjH5H1d80r0MViFI8P04cl5v5pGml
X-Google-Smtp-Source: AGHT+IFCkAMvyLIpE8K44Jvpwt9d2HdlN85/9ikoQLek6Uc5JY1c4cWY9m1iWbbUy+Cv02lY0HyOow==
X-Received: by 2002:a05:6902:2512:b0:e08:7600:4697 with SMTP id 3f1490d57ef6-e087b8e2962mr80056276.46.1721433674402;
        Fri, 19 Jul 2024 17:01:14 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:86d1:0:b0:dfa:77ba:dc1f with SMTP id 3f1490d57ef6-e05fdb9c58dls1009753276.2.-pod-prod-06-us;
 Fri, 19 Jul 2024 17:01:13 -0700 (PDT)
X-Received: by 2002:a05:690c:7:b0:663:ddc1:eab8 with SMTP id 00721157ae682-66a68f74be3mr701637b3.4.1721433673085;
        Fri, 19 Jul 2024 17:01:13 -0700 (PDT)
Received: by 2002:a05:690c:2d11:b0:66a:8967:a513 with SMTP id 00721157ae682-66a8967cff9ms7b3;
        Fri, 19 Jul 2024 16:58:03 -0700 (PDT)
X-Received: by 2002:a05:690c:17:b0:64a:d9c2:42c1 with SMTP id 00721157ae682-66a65e64cf6mr838487b3.5.1721433482643;
        Fri, 19 Jul 2024 16:58:02 -0700 (PDT)
Date: Fri, 19 Jul 2024 16:58:02 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com>
In-Reply-To: <Zpp6U00Mp7Z/bOej@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com>
 <Zpm73WHBNIkkIT0Y@petertodd.org>
 <CALZpt+HJvBXM_geK7JC8umrt1goq8bc+pnY0mk+o+r_+bjrtew@mail.gmail.com>
 <Zpp6U00Mp7Z/bOej@petertodd.org>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The
 Lack of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_571870_921966128.1721433482429"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_571870_921966128.1721433482429
Content-Type: multipart/alternative; 
	boundary="----=_Part_571871_291956564.1721433482429"

------=_Part_571871_291956564.1721433482429
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> A is a low fee-rate transaction with opt-in disabled. When it is=20
broadcast, it
> reaches 100% of nodes.
>=20
> 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 fac=
t
> relay A2 to non-full-rbf nodes they're peered with. But those nodes=20
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=20
transaction A2
will propagate along the `mempoolfullrbf=3D1` transaction-relay network=20
paths. I think
the initial description could have been clearer with this additional=20
observation, as
somehow I think there is the low-odd marginal situation where the attacker=
=20
broadcasting
full-node is randomly peered with only transaction-relay `mempoolfullrbf=3D=
0`=20
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=
=20
an
> attack primarily against nodes that have full-RBF disabled (though those=
=20
nodes
> will waste the bandwidth of their full-RBF peers).

Yes I agree with this observation. In a world where a supermajority of=20
miners is running
full-rbf as policy settings, I'll let what the corrollorary means in terms=
=20
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,=
=20
it
> works fine even if 100% of hash power is mining A2.
>=20
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a=20
fee-rate
> only slightly higher than A that is still below the minimum economic=20
fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is=
=20
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=20
interesting as there
is no strict attacker necessity for A2 to be mined at some point in time=20
for the attack
effect to play out. Note, see bitcoin core issue #14895 were few years ago=
=20
such mempool
adaptive attacker were pondered about transaction pinnings affecting=20
lightning.

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

See above.

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

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

> Again, A2 does not need to pay a high enough fee-rate to be economical to=
=20
mine.
> So there are no particular latency requirements between when A, B, and A2=
=20
are
> broadcast.
>=20
> All that is necessary for this class of attack is there be at least one=
=20
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=20
network
mepool feerate segment asymmetries arising from transaction-relay policy=20
divergence.

> This attack is simply a variant of attacks that were publicly disclosed=
=20
months
> ago, that Core has chosen not to respond to at all, so the exact timefram=
e
> isn't very relevant. This is not actually a new class of attack; the whol=
e
> point of my disclosure is to show that Core does not actually care about=
=20
this
> class of attack by showing they won't even bother to fix the simplest=20
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=
=20
bitcoin dev
circles conversations about network DoS. To point out more historical=20
conversation this
class of attack was pointed out by gmaxwell years ago on the bitcoin core=
=20
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=
=20
mailing list
of malovencly, it's more constructive to question if this set of people=20
still have the
competency and bitcoin security culture to diligently understand and=20
address this class
of attacks (and with gmaxwell in its own recent words on another channel=20
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=20
assigned to
genuine incompetence or willful laziness.

> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd=20
publish
> if I couldn't get any response. I publicly verified that achow (and=20
others) had
> received my email on Jul 10th, with achow promising a response. On Jul=20
12th
> rather than replying, Core closed my full-RBF pull-req that fixes this=20
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=20
list,
> and finally got achow and glozow to respond in a perfunctory fashion=20
(glozow
> recommended that I open a new full-RBF pull-req). So I published this on=
=20
Jul
> 18th after my replies to achow and glozow didn't get any response. This=
=20
whole
> time no-one has asked me to not publish this attack; asking me to keep=20
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.
>=20
> Core could have *easily* responded by simply merging my pull-req to enabl=
e
> full-RBF by default, a trivial change that has had lots of ACKs from=20
technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would=
=20
have
> questioned merging that pull-req. They chose not to do so, proving my=20
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=20
reasonable
in matters of formal responsiveness.

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

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

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

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

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

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

Best,
Antoine
ots hash: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464

Le vendredi 19 juillet 2024 =C3=A0 19:27:40 UTC+1, Peter Todd a =C3=A9crit =
:

> On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> > Hi Peter,
> >=20
> > > I think you need to re-read the attack carefully before we discuss th=
is
> > > 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=
=20
> is
> > an
> > > essentially linear function of % of full-rbf miners.
> >=20
> > This is not the % of hash power mining _full-rbf_ I was pointing to, ju=
st
> > the indistinct
> > total % of hash power mining.
> >=20
> > In my understanding, this is the scenario:
> > - Alice broadcasts small size, low-feerate transaction opt-in disabled =
A=20
> to
> > 99% of the miners+network nodes mempools
> > - Alice broadcasts a double-spend of A, a high-feerate transaction A2 t=
o
> > Mark, a single miner
> > - Network nodes does not relay transaction A to Mark and vice-versa Mar=
k
> > 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=20
> 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 fac=
t
> relay A2 to non-full-rbf nodes they're peered with. But those nodes rejec=
t=20
> 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=20
> 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=
=20
> 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,=
=20
> 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=20
> fee-rate
> only slightly higher than A that is still below the minimum economic=20
> 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=20
> attack
> > vector you're describing.
>
> You're not far off. But I believe you are still misunderstanding details,=
=20
> as
> described above.
>
> > The child B can be extended with a full chain of useless children withi=
n
> > max mempool limits.
>
> Correct. Although it's probably simplest to just pick a B that is large=
=20
> 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=20
> 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=
=20
> mine.
> So there are no particular latency requirements between when A, B, and A2=
=20
> are
> broadcast.
>
> All that is necessary for this class of attack is there be at least one=
=20
> 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 issu=
e=20
> to
> > the sec mailing
> > list and the public disclosure of your email.
>
> This attack is simply a variant of attacks that were publicly disclosed=
=20
> months
> ago, that Core has chosen not to respond to at all, so the exact timefram=
e
> isn't very relevant. This is not actually a new class of attack; the whol=
e
> point of my disclosure is to show that Core does not actually care about=
=20
> this
> class of attack by showing they won't even bother to fix the simplest=20
> possible
> version, even when the fix is trivial.
>
> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd=20
> publish
> if I couldn't get any response. I publicly verified that achow (and=20
> others) had
> received my email on Jul 10th, with achow promising a response. On Jul 12=
th
> rather than replying, Core closed my full-RBF pull-req that fixes this=20
> 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=20
> list,
> and finally got achow and glozow to respond in a perfunctory fashion=20
> (glozow
> recommended that I open a new full-RBF pull-req). So I published this on=
=20
> Jul
> 18th after my replies to achow and glozow didn't get any response. This=
=20
> whole
> time no-one has asked me to not publish this attack; asking me to keep th=
is
> 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 enabl=
e
> full-RBF by default, a trivial change that has had lots of ACKs from=20
> technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would=
=20
> have
> questioned merging that pull-req. They chose not to do so, proving my poi=
nt
> 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 almo=
st
> every disclosed attack has gotten a response within 24 hours, with the=20
> longest
> about 72 hours (I just skimmed through my archives to double check).=20
> Failing to
> respond at all is very unusual.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
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 e=
mail 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.

------=_Part_571871_291956564.1721433482429
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<br /><br />&gt; A is a low fee-rate transaction with opt-in disab=
led. When it is broadcast, it<br />&gt; reaches 100% of nodes.<br />&gt; <b=
r />&gt; A2 is a full-RBF double-spend of A. When it is broadcast, it reach=
es all<br />&gt; nodes/miners with full-RBF enabled, replacing A. Full-RBF =
nodes do in fact<br />&gt; relay A2 to non-full-rbf nodes they're peered wi=
th. But those nodes reject A2<br />&gt; as it is a full-RBF replacement.<br=
 />&gt;<br />&gt; We are *not* trying to limit A2 to a single miner, or do =
any kind of<br />&gt; simultaneous broadcast. We don't need to.<br /><br />=
Okay, I see. Effectively, the attack holds are you're describing as transac=
tion A2<br />will propagate along the `mempoolfullrbf=3D1` transaction-rela=
y network paths. I think<br />the initial description could have been clear=
er with this additional observation, as<br />somehow I think there is the l=
ow-odd marginal situation where the attacker broadcasting<br />full-node is=
 randomly peered with only transaction-relay `mempoolfullrbf=3D0` neighbori=
ng<br />nodes, and as such the bandwidth waste denial-of-service negligeabl=
e.<br /><br />This is correct there is no concurrent broadcast necessarily =
involved.<br /><br />&gt; The % of miners/nodes that accept B isn't particu=
larly relevant; this is an<br />&gt; attack primarily against nodes that ha=
ve full-RBF disabled (though those nodes<br />&gt; will waste the bandwidth=
 of their full-RBF peers).<br /><br />Yes I agree with this observation. In=
 a world where a supermajority of miners is running<br />full-rbf as policy=
 settings, I'll let what the corrollorary means in terms of transaction-rel=
ay<br />network decentralization to be fully explained by someone else.<br =
/><br />&gt; Again, the attack does not depend on a single miner receiving =
A2. Indeed, it<br />&gt; works fine even if 100% of hash power is mining A2=
.<br />&gt; <br />&gt; Also, A2 isn't necessarily what gets mined. A2 can b=
e broadcast with a fee-rate<br />&gt; only slightly higher than A that is s=
till below the minimum economic fee-rate,<br />&gt; and then replaced later=
 with an even higher fee-rate double-spend that is a<br />&gt; high enough =
fee-rate to get mined. Remember that RBF Rule #6 prohibits a<br />&gt; repl=
acement if the fee-rate of the replacement is lower than the directly<br />=
&gt; replaced transaction.<br /><br />Yes, I think what you're pointing is =
what makes the attack quite interesting as there<br />is no strict attacker=
 necessity for A2 to be mined at some point in time for the attack<br />eff=
ect to play out. Note, see bitcoin core issue #14895 were few years ago suc=
h mempool<br />adaptive attacker were pondered about transaction pinnings a=
ffecting lightning.<br /><br />&gt; You're not far off. But I believe you a=
re still misunderstanding details, as<br />described above.<br /><br />See =
above.<br /><br />&gt; Correct. Although it's probably simplest to just pic=
k a B that is large enough<br />to max out the mempool limits on its own.<b=
r /><br />I believe this observation can be still game out more at the adva=
ntage of the attacker.<br /><br />&gt; Again, A2 does not need to pay a hig=
h enough fee-rate to be economical to mine.<br />&gt; So there are no parti=
cular latency requirements between when A, B, and A2 are<br />&gt; broadcas=
t.<br />&gt; <br />&gt; All that is necessary for this class of attack is t=
here be at least one miner<br />&gt; willing to mine A2 (or a further doubl=
e-spend), who rejects A.<br /><br />Yes, I see more what is interesting wit=
h this attack by playing out on network<br />mepool feerate segment asymmet=
ries arising from transaction-relay policy divergence.<br /><br />&gt; This=
 attack is simply a variant of attacks that were publicly disclosed months<=
br />&gt; ago, that Core has chosen not to respond to at all, so the exact =
timeframe<br />&gt; isn't very relevant. This is not actually a new class o=
f attack; the whole<br />&gt; point of my disclosure is to show that Core d=
oes not actually care about this<br />&gt; class of attack by showing they =
won't even bother to fix the simplest possible<br />&gt; version, even when=
 the fix is trivial.<br /><br />As I said few months ago, I don't think thi=
s is a new class of attacks in bitcoin dev<br />circles conversations about=
 network DoS. To point out more historical conversation this<br />class of =
attack was pointed out by gmaxwell years ago on the bitcoin core pr #16698 =
few<br />years ago [0].<br /><br />[0] https://github.com/bitcoin/bitcoin/p=
ull/16698#issuecomment-571399346<br /><br />I think rather to accuse people=
 currently maintaining the bitcoin-core sec mailing list<br />of malovencly=
, it's more constructive to question if this set of people still have the<b=
r />competency and bitcoin security culture to diligently understand and ad=
dress this class<br />of attacks (and with gmaxwell in its own recent words=
 on another channel being far far less<br />active in bitcoin protocol dev =
it's not a purely rhetorical question).<br /><br />In general, there is no =
necessity to assign to malevolency what can be assigned to<br />genuine inc=
ompetence or willful laziness.<br /><br />&gt; But anyway, I disclosed on J=
ul 7th giving a 7 day deadline before I'd publish<br />&gt; if I couldn't g=
et any response. I publicly verified that achow (and others) had<br />&gt; =
received my email on Jul 10th, with achow promising a response. On Jul 12th=
<br />&gt; rather than replying, Core closed my full-RBF pull-req that fixe=
s this issue.<br />&gt; On Jul 15th I reached out again, and after someone =
else pointed out that<br />&gt; failing to reply to me was degrading the va=
lue of the security mailing list,<br />&gt; and finally got achow and glozo=
w to respond in a perfunctory fashion (glozow<br />&gt; recommended that I =
open a new full-RBF pull-req). So I published this on Jul<br />&gt; 18th af=
ter my replies to achow and glozow didn't get any response. This whole<br /=
>&gt; time no-one has asked me to not publish this attack; asking me to kee=
p this<br />&gt; fact about mempools a secret would be rather duplicitous g=
iven that a key<br />&gt; argument for TRUC/V3 relies on "free" relay attac=
ks not being possible.<br />&gt; <br />&gt; Core could have *easily* respon=
ded by simply merging my pull-req to enable<br />&gt; full-RBF by default, =
a trivial change that has had lots of ACKs from technical<br />&gt; reviewe=
rs, which ~100% of hash power has adopted. No-one reasonable would have<br =
/>&gt; questioned merging that pull-req. They chose not to do so, proving m=
y point<br />&gt; that none of this has anything to do with a genuine techn=
ical concern.<br /><br />Okay, with more information I think both achow and=
 glozow answers are reasonable<br />in matters of formal responsiveness.<br=
 /><br />That they pointed out to carry with a public process to fix that c=
ategory of attacks<br />only give more ground at my hypothesis highlighted =
above that it can be a problem of<br />security culture knowledge or lack o=
f experience know-how in handling "half" / full <br />covert fixes.<br /><b=
r />Sadly, I must say this is matching my historical experience with the bi=
tcoin security<br />mailing list (and I had far more seasoned interlocutors=
) or the ones of other security<br />issues reporters I'm aware off.<br /><=
br />&gt; I was previously on the bitcoin-security mailing list for years, =
and almost<br />&gt; every disclosed attack has gotten a response within 24=
 hours, with the longest<br />&gt; about 72 hours (I just skimmed through m=
y archives to double check). Failing to<br />&gt; respond at all is very un=
usual.<br /><br />As said in one my previous email, I'm still curious about=
 achow101 explaining publicly<br />why you have been kicked-out of the bitc=
oin-security mailing list, when you were certainly<br />more senior than ac=
how101 in matters of base-layer security issues or even hard technical<br /=
>issues like consensus interactions (e.g bip65). I'll re-iterate my respect=
 towards achow101<br />as a maintainer from years of collaboration, though =
this is a topic worthy of an answer.<br /><br />Without a public answer und=
er 2 weeks, I'll remove achow101 from among the future security<br />report=
s recipients I can make about the bitcoin core project, be it a report that=
 is codebase-only<br />or any security issues related to the base layer and=
 affecting all full-nodes implementations<br />or the mining stack.<br /><b=
r />Under the information shared and from my perspective, achow101 argued c=
onduct of playing<br />for unknown reasons with an adminstrative communicat=
ion endpoint creates a moral hazard<br />and this would be further unethica=
l for me as a security researcher to share sensitive security<br />informat=
ion with that bitcoin maintainer.<br /><br />Best,<br />Antoine<br />ots ha=
sh: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464<br /><=
br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le v=
endredi 19 juillet 2024 =C3=A0 19:27:40 UTC+1, Peter Todd a =C3=A9crit=C2=
=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Fri, =
Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
<br>&gt; Hi Peter,
<br>&gt;=20
<br>&gt; &gt; I think you need to re-read the attack carefully before we di=
scuss this
<br>&gt; &gt; further. The % of hash power mining full-rbf does not signifi=
cantly
<br>&gt; change the
<br>&gt; &gt; cost efficiency of the attack as long as the fee-rate of the =
B
<br>&gt; transaction(s)
<br>&gt; &gt; is below the minimum economic fee-rate necessary for miners t=
o mine a
<br>&gt; &gt; transaction. Above the minimum economic fee-rate, the cost ef=
ficiency is
<br>&gt; an
<br>&gt; &gt; essentially linear function of % of full-rbf miners.
<br>&gt;=20
<br>&gt; This is not the % of hash power mining _full-rbf_ I was pointing t=
o, just
<br>&gt; the indistinct
<br>&gt; total % of hash power mining.
<br>&gt;=20
<br>&gt; In my understanding, this is the scenario:
<br>&gt; - Alice broadcasts small size, low-feerate transaction opt-in disa=
bled A to
<br>&gt; 99% of the miners+network nodes mempools
<br>&gt; - Alice broadcasts a double-spend of A, a high-feerate transaction=
 A2 to
<br>&gt; Mark, a single miner
<br>&gt; - Network nodes does not relay transaction A to Mark and vice-vers=
a Mark
<br>&gt; does not relay transaction A2 to network nodes
<br>
<br>Here I think you&#39;ve misunderstood the attack.
<br>
<br>A is a low fee-rate transaction with opt-in disabled. When it is broadc=
ast, it
<br>reaches 100% of nodes.
<br>
<br>A2 is a full-RBF double-spend of A. When it is broadcast, it reaches al=
l
<br>nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in f=
act
<br>relay A2 to non-full-rbf nodes they&#39;re peered with. But those nodes=
 reject A2
<br>as it is a full-RBF replacement.
<br>
<br>We are *not* trying to limit A2 to a single miner, or do any kind of
<br>simultaneous broadcast. We don&#39;t need to.
<br>
<br>&gt; - Alice broadcasts a child B of transaction A to 99% of the miners=
+network
<br>&gt; nodes mempools
<br>
<br>The % of miners/nodes that accept B isn&#39;t particularly relevant; th=
is is an
<br>attack primarily against nodes that have full-RBF disabled (though thos=
e nodes
<br>will waste the bandwidth of their full-RBF peers).
<br>
<br>&gt; - Mark, the single miner confirms in a block A2, rendering as a wa=
ste A+B
<br>&gt; network bandwidth
<br>
<br>Again, the attack does not depend on a single miner receiving A2. Indee=
d, it
<br>works fine even if 100% of hash power is mining A2.
<br>
<br>Also, A2 isn&#39;t necessarily what gets mined. A2 can be broadcast wit=
h a fee-rate
<br>only slightly higher than A that is still below the minimum economic fe=
e-rate,
<br>and then replaced later with an even higher fee-rate double-spend that =
is a
<br>high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits =
a
<br>replacement if the fee-rate of the replacement is lower than the direct=
ly
<br>replaced transaction.
<br>
<br>&gt; Correct if I&#39;m wrong with this scenario and if it does not mat=
ch the attack
<br>&gt; vector you&#39;re describing.
<br>
<br>You&#39;re not far off. But I believe you are still misunderstanding de=
tails, as
<br>described above.
<br>
<br>&gt; The child B can be extended with a full chain of useless children =
within
<br>&gt; max mempool limits.
<br>
<br>Correct. Although it&#39;s probably simplest to just pick a B that is l=
arge enough
<br>to max out the mempool limits on its own.
<br>
<br>&gt; The attack efficiency (i.e the total vB of bandwidth network waste=
) is
<br>&gt; dependent on the delay
<br>&gt; by which transaction A2 is included in Mark&#39;s block template a=
nd
<br>&gt; subsequently mined. Back to
<br>&gt; my observation, higher are Mark hashrate ressources, less there is=
 latency
<br>&gt; to let transaction B
<br>&gt; spontaneously propagate on the network, or for Alice to (re)-broad=
cast in
<br>&gt; cycle.
<br>
<br>Again, A2 does not need to pay a high enough fee-rate to be economical =
to mine.
<br>So there are no particular latency requirements between when A, B, and =
A2 are
<br>broadcast.
<br>
<br>All that is necessary for this class of attack is there be at least one=
 miner
<br>willing to mine A2 (or a further double-spend), who rejects A.
<br>
<br>&gt; All that said, I think my open question to you at the beginning of=
 my
<br>&gt; answer is still there,
<br>&gt; i.e how much time has been left between the private report of this=
 issue to
<br>&gt; the sec mailing
<br>&gt; list and the public disclosure of your email.
<br>
<br>This attack is simply a variant of attacks that were publicly disclosed=
 months
<br>ago, that Core has chosen not to respond to at all, so the exact timefr=
ame
<br>isn&#39;t very relevant. This is not actually a new class of attack; th=
e whole
<br>point of my disclosure is to show that Core does not actually care abou=
t this
<br>class of attack by showing they won&#39;t even bother to fix the simple=
st possible
<br>version, even when the fix is trivial.
<br>
<br>But anyway, I disclosed on Jul 7th giving a 7 day deadline before I&#39=
;d publish
<br>if I couldn&#39;t get any response. I publicly verified that achow (and=
 others) had
<br>received my email on Jul 10th, with achow promising a response. On Jul =
12th
<br>rather than replying, Core closed my full-RBF pull-req that fixes this =
issue.
<br>On Jul 15th I reached out again, and after someone else pointed out tha=
t
<br>failing to reply to me was degrading the value of the security mailing =
list,
<br>and finally got achow and glozow to respond in a perfunctory fashion (g=
lozow
<br>recommended that I open a new full-RBF pull-req). So I published this o=
n Jul
<br>18th after my replies to achow and glozow didn&#39;t get any response. =
This whole
<br>time no-one has asked me to not publish this attack; asking me to keep =
this
<br>fact about mempools a secret would be rather duplicitous given that a k=
ey
<br>argument for TRUC/V3 relies on &quot;free&quot; relay attacks not being=
 possible.
<br>
<br>Core could have *easily* responded by simply merging my pull-req to ena=
ble
<br>full-RBF by default, a trivial change that has had lots of ACKs from te=
chnical
<br>reviewers, which ~100% of hash power has adopted. No-one reasonable wou=
ld have
<br>questioned merging that pull-req. They chose not to do so, proving my p=
oint
<br>that none of this has anything to do with a genuine technical concern.
<br>
<br>I was previously on the bitcoin-security mailing list for years, and al=
most
<br>every disclosed attack has gotten a response within 24 hours, with the =
longest
<br>about 72 hours (I just skimmed through my archives to double check). Fa=
iling to
<br>respond at all is very unusual.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1721519812863000&amp;usg=3DAOvVaw3=
bBEKCB24L8g6lhaIGBm6b">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1721519812863000&amp;usg=3DAOvVaw2B8O2Nln7O-B=
vv_VH2s1qn">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com</a>.=
<br />

------=_Part_571871_291956564.1721433482429--

------=_Part_571870_921966128.1721433482429--