From mboxrd@z Thu Jan 1 00:00:00 1970
Delivery-date: Fri, 19 Jul 2024 17:01:20 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBRX45O2AMGQEWI3OCNQ@googlegroups.com>)
id 1sUxXK-0004um-NW
for bitcoindev@gnusha.org; Fri, 19 Jul 2024 17:01:20 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e032d4cf26asf5403452276.3
for <bitcoindev@gnusha.org>; Fri, 19 Jul 2024 17:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1721433672; x=1722038472; 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=IIHrT2YY5IIvqcKCXp2AIWV6zk7WOX5iUQCfDv7nD4s=;
b=ZZjtR5mjAJOajNgQRJoWBYMxMUminSPuPonJDYXPiF8d97ZuzT6pIJBR9VEozOwqYH
Y+/meXoYYbuUCcnGRt4/w515sUCLIuajxXqbm8r3qwzDVZ2rW5RAKlpjA7daPw8s0Ep2
Lh9Eq3pv7ntKIs3v6oATerlwrTXqvcjwGQCagOPbp1wOEomYTgQCI6S29I3jgcWh5AY0
YU5UB6E5pJ2BkXwbf1MFwfGKMcPwfFEN7U2xLFKWspjq1l125oiFliPMOiQo8mmGV8+f
v7bHvBbQZFvhmRoiHv494DvuUIpqA7cQzXfVPoXgUQyiRNDA68Oqobeg6vX9v3aMAHQJ
7LGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1721433672; x=1722038472; 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=IIHrT2YY5IIvqcKCXp2AIWV6zk7WOX5iUQCfDv7nD4s=;
b=PQmoD6I2z8PNq28hb0tH6BEoe89MEVl3xcx3g8oZ1/nelmrswRVN+an1q5r7QnASjJ
5ndzMFoJ8uLt01dDDkzuXU0vSvH0adVkVuBAFDWjKvUh/iDjV2v/M0vKLMSMGlk4yv69
IUojBnAmarECNkg5Jbop0jKnrp65N19s2EROYCB6znsGI81TixwROpnfyR+l1Y9uNlAV
9fSYWZT5wxvlV7PFTyDa1BefNeZKcB1zZmWUSaKyx5hMROfzu5ckuYhNrFbZAvpL06e0
hJi9//6HKfKgQVJBstqbhM8gzdFwJnltfdDS32PO8FYdoNDaCTT+hZKNXyIwuMuGGkiO
Nudw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721433672; x=1722038472;
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=IIHrT2YY5IIvqcKCXp2AIWV6zk7WOX5iUQCfDv7nD4s=;
b=AAI8ifEBj2Mr0bPFznpQTzvnKn7Gd8NTfF+C+y++oN3RgBX6SQz4T+AOhKEMypBcy3
ucrO1VJgyinYvM1WzshBDuXcHfuPMu0gFNxKZ+HhHtnYkwvGHrlPjfPpPUVw8F+6XDsU
8xgs4uSDojZjFbuzzFn5UVGfyIogWZgWfAA+54RZPqx9cI7yRCkNoMRKWLcav5IdmNhN
ezZ3Ktd7bCzUJD0FyChBXK+KOW4YmqCRdeYk6x16sjABD6GpVQpX/e79d/9OQmwecSv9
wUbJRW+VoqnIeBpwKXp4aSAxPR9WR53q8DQKZCrCVR43pezsYEUkAOkl0R6w3J8T4z1x
TBrw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCW2zne/2ys8X2gXH+Dz8n1LfEHLgaxa+du+7nlHL2+HgAStjdXDphLa0jF35eLILGpZKO3xIIs7GEbzIxPcuN4Ow8m+PTk=
X-Gm-Message-State: AOJu0YzQZndHXVXGAV5AvofsWhWCZmSZEpPGP0V88rZTGwdmXEmfto8y
uvOjB40SSn3IUuuUJEdCfhyOL9cpIu5RBmfrAlDDe/VH0kw/o8LG
X-Google-Smtp-Source: AGHT+IEesX6yFrulJ0B/NKqoleq+MhscYJrGYy4Y6Ai7GqOVQ4ySPU4e9KcATHUHTEgkPW9a0i32nw==
X-Received: by 2002:a05:6902:c0d:b0:e05:ff2a:aa49 with SMTP id 3f1490d57ef6-e0870185af9mr1508222276.30.1721433672224;
Fri, 19 Jul 2024 17:01:12 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:1348:b0:dfe:f69f:99 with SMTP id
3f1490d57ef6-e05fdb6fc73ls4271645276.2.-pod-prod-02-us; Fri, 19 Jul 2024
17:01:10 -0700 (PDT)
X-Received: by 2002:a05:690c:86:b0:627:a6cc:d227 with SMTP id 00721157ae682-66a66062deemr249027b3.5.1721433670258;
Fri, 19 Jul 2024 17:01:10 -0700 (PDT)
Received: by 2002:a05:690c:26c7:b0:627:7f59:2eee with SMTP id 00721157ae682-6691747e85ems7b3;
Fri, 19 Jul 2024 16:56:53 -0700 (PDT)
X-Received: by 2002:a05:690c:f06:b0:648:3f93:68e0 with SMTP id 00721157ae682-66a66837666mr442707b3.6.1721433412285;
Fri, 19 Jul 2024 16:56:52 -0700 (PDT)
Date: Fri, 19 Jul 2024 16:56:52 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com>
In-Reply-To: <18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com>
Subject: [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_278078_1820075485.1721433412057"
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_278078_1820075485.1721433412057
Content-Type: multipart/alternative;
boundary="----=_Part_278079_2093069652.1721433412057"
------=_Part_278079_2093069652.1721433412057
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi /dev/fd0
> The last comment in the pull request suggests opening a new pull request=
=20
to enable full RBF by default, referencing the one closed due to off-topic=
=20
comments.
I'm interested if you can propose a formal or mathematical definition of=20
what constitute
an in-topic of off-topic comments on a matters like full RBF, which has=20
been controversial
for like a decade. I can only think such definition could make future=20
conversations about
the boundaries of what is in / off bitcoin engineering topic more objective=
.
> It seems that you are the one trying to politicize this issue.
Let's be realistic on the state of bitcoin core security issues handling in=
=20
the recent words of
a group of some active contributors:
"The project has historically done a poor job at publicly disclosing=20
security-critical bugs, whether
externally reported or found by contributors. This has led to a situation=
=20
where a lot of users perceive
Bitcoin Core as never having bugs. This perception is dangerous and,=20
unfortunately, not accurate." [0].
[0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
Again, I'm interested if you can propose a formal or mathematical=20
definition of what constitute
a reasonable bitcoin core vulnerability handling policy and that way give=
=20
more ground on qualifying
if a present situation is falling out of this reasonable guidelines and=20
that can be qualified more=20
objectively as "politics".
I think we have a mailing list to favorize textual long format and=20
encourage a more self-reflexive
mode of reasoning in the conduct of bitcoin engineering discussions. I=20
believe comments not bringing
new factual information or pointing to past experiences or concrete piece=
=20
of information are better
left to twitter / nostr / reddit, whatever other communication channel=20
where the scientific and
ethics of conversation standards are less stringent.
All that said, I'm thinking to agree that the usage of all political=20
rhethoric is a fallacy better
left for expressions on other communication channels and this is note wise=
=20
to bundle it with novel
technical information, as from the outset it does not favor to concentrate=
=20
the discussion on the fact
and logical reasoning themselves. Even more, political rhetoric very easily=
=20
downgrade in moralistic
contest among protagonists on who has the monopole of the good / truth.=20
Somehow bitcoin is beyond
good and evil (-- under some long-term and abstract perspective).
Best,
Antoine
ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev /fd0 a =C3=A9crit :
> Hi Peter,
>
> > I didn't get a substantive
> > response from Bitcoin Core, other than Core closing the my pull-req=20
> enabling
> > full-RBF by default that would fix this specific vulnerability.
>
> The last comment in the pull request suggests opening a new pull request=
=20
> to enable full RBF by default, referencing the one closed due to off-topi=
c=20
> comments.=20
>
> > But read on, this is quite an odd case of Core politics, and the story=
=20
> is not
> > as simple as Core refusing to fix a vulnerability.
>
> It seems that you are the one trying to politicize this issue.=20
>
> /dev/fd0
> floppy disk guy
>
> On Thursday, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:
>
>> # Summary=20
>>
>> This is a public disclosure of a vulnerability that I previously=20
>> disclosed to=20
>> the bitcoin-security mailing list. It's an easy vulnerability to fix.=20
>> Although=20
>> as with other "free" relay attacks I've disclosed, I didn't get a=20
>> substantive=20
>> response from Bitcoin Core, other than Core closing the my pull-req=20
>> enabling=20
>> full-RBF by default that would fix this specific vulnerability.=20
>>
>> But read on, this is quite an odd case of Core politics, and the story i=
s=20
>> not=20
>> as simple as Core refusing to fix a vulnerability. Also, I've including =
a=20
>> fun=20
>> homework problem at the end: figure out how TRUC/V3 transactions itself=
=20
>> creates=20
>> a "free" relay attack.=20
>>
>>
>> # Background=20
>>
>> This is just one of a few "free" relay attacks that I have recently=20
>> disclosed,=20
>> including, but not limited to:=20
>>
>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024=20
>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg=20
>>
>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st=20
>> 2024=20
>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo=20
>>
>> The term "free relay attack" simply refers to any mechanism where=20
>> transaction=20
>> data can be broadcast at unusually low cost; the "free" in "free relay"=
=20
>> is a=20
>> misnomer as all these attacks do in fact have some cost.=20
>>
>> This particular attack isn't significantly different than the other=20
>> attacks=20
>> I've disclosed. With one important exception: unlike those other attacks=
,=20
>> fixing this particular attack would be quite easy, by enabling full-rbf=
=20
>> by=20
>> default. So I disclosed it to the bitcoin-security mailing list as a=20
>> test: does=20
>> Bitcoin Core actually care about free relay attacks? My hypothesis is=20
>> that Core=20
>> does not, as they know full well that "free" relay is an unavoidable=20
>> problem;=20
>> I've received absolutely no feedback from any Bitcoin Core members for=
=20
>> the=20
>> other disclosed attacks, beyond achow using my disclosure of the RBF Rul=
e=20
>> #6=20
>> attack as an excuse to remove me from the bitcoin-security mailing list.=
=20
>>
>> The fact that Core doesn't actually care about "free" relay attacks is=
=20
>> relevant=20
>> to TRUC/V3 Transactions. As per BIP-431:=20
>>
>> "The primary problem with [RBFR proposals] is the potential for free=20
>> relay and DDoS attacks.=20
>>
>> Removing Rule 3 and 4 in general would allow free relay [27]."=20
>>
>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a4=
28aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate=20
>>
>> I believe the authors of that BIP are fully aware of the fact that "free=
"=20
>> relay=20
>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and=
=20
>> don't=20
>> want to admit that they've wasted a large amount of engineering time on =
a=20
>> bad=20
>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as=
=20
>> the many=20
>> "free" relay attacks I've disclosed clearly show that claiming RBFR woul=
d=20
>> "allow" free relay is simply not true.=20
>>
>> Notably, full-RBF is _itself_ a transaction pinning fix for many=20
>> use-cases;=20
>> part of the TRUC/V3 standard is to force full-RBF behavior for V3=20
>> transactions.=20
>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a=20
>> second=20
>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF=
=20
>> option=20
>> removed from Core in the first place. If not for this dumb bit of Core=
=20
>> politics, I'm sure my year-old pull-req to enable full-RBF by default=20
>> would=20
>> have been merged many months ago, as almost all hashpower has adopted=20
>> full-RBF=20
>> making objections based on "zeroconf" absurd.=20
>>
>>
>> # The Attack=20
>>
>> If you're a competent Bitcoin engineer, familiar with how mempools work,=
=20
>> you've=20
>> probably figured it out already based on the title: obviously, if a high=
=20
>> percentage of miners are adopting a policy that Bitcoin Core nodes are=
=20
>> not, you=20
>> can cheaply consume transaction relay bandwidth by simply relaying=20
>> transations=20
>> that miners are rejecting.=20
>>
>> Specifically, do the following:=20
>>
>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.=
=20
>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.=
=20
>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with=
=20
>> BIP-125=20
>> opt-in enabled. ~100% of miners will reject B, as it spends an input not=
=20
>> in=20
>> their mempools. However Bitcoin Core nodes will waste bandwidth=20
>> propagating=20
>> B.=20
>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will=
=20
>> waste=20
>> bandwidth propagating Bn's that ~100% of miners are ignoring.=20
>> 5. Double-spend A2 to recover your funds and do it all over again (or if=
=20
>> A2 had=20
>> a high enough fee-rate, just wait for it to be mined).=20
>>
>> The cost to relay each B transaction depends on the fee-rate of B. Since=
=20
>> Bitcoin Core defaults to a fairly large mempool, the minimum relay=20
>> fee-rate is=20
>> typically well below the economic fee-rate required for miners to=20
>> actually mine=20
>> a transaction; Core accepts transactions that are uneconomical for miner=
s=20
>> to=20
>> mine for the forseeable future.=20
>>
>> For example, at the moment typical mempools require transactions to pay=
=20
>> at=20
>> least 1sat/vB, while there are hundreds of MvB worth of transactions=20
>> paying=20
>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less=
=20
>> than=20
>> 4sat/VB are extremely unlikely to get mined in the nearish future.=20
>>
>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB=
=20
>> would=20
>> have almost zero cost as the probability of those transactions getting=
=20
>> mined is=20
>> nearly zero. This is true _regardless_ of what % of miners are mining=20
>> full-RBF!=20
>> As long as you can get at least one miner to mine the A double-spend, th=
e=20
>> attack only costs what it cost to get A mined.=20
>>
>> If B's are broadcast at a higher fee-rate than the minimum economical=20
>> fee-rate,=20
>> then the % of full-RBF miners matters. For example, if only 99% of miner=
s=20
>> mine=20
>> full-RBF, the chance of a B transaction getting mined per block is about=
=20
>> 1%, so=20
>> the amortized cost of broadcasting B is about 1% of whatever total fee=
=20
>> the=20
>> highest fee-rate variant of B pays.=20
>>
>> For an attacker who does not need any B to be broadcast, the cost saving=
s=20
>> to=20
>> use of relay bandwidth is approximately the ratio of the difference in=
=20
>> size=20
>> between B and and A. With a maximum standard transaction size of 100KvB,=
=20
>> or=20
>> 400KB serialized size, this ratio is on the order of 5000:1, times the=
=20
>> total=20
>> number of B variants broadcast, and the % chance of each B being mined;=
=20
>> it's a=20
>> few orders of magnitude.=20
>>
>> Of course, as mentioned above, this is just one of *many* "free" relay=
=20
>> attacks,=20
>> so fixing this particular issue doesn't change much.=20
>>
>>
>> # Attackers Who Benefit From B Getting Mined=20
>>
>> Some attackers actually need B to get mined. For example, imagine an=20
>> exchange=20
>> who needs to do large consolidation transactions. They could use this=20
>> attack=20
>> (and some attacks like it) as a way to goad users and miners into mining=
=20
>> consolidation transactions for them at low cost. In this variant of the=
=20
>> attack,=20
>> the attacker would pad the size of B with consolidation spends that they=
=20
>> needed=20
>> to do anyway. Someone who tried to stop the attack by getting B mined (e=
g=20
>> via=20
>> mempool.space's transaction accellerator) would simply be paying the=20
>> attacker's=20
>> fees for them.=20
>>
>> Obviously, this strategy is only relevant for B's below the economic=20
>> fee-rate.=20
>> However, the weaker version of this strategy is to parallize the attack,=
=20
>> and do=20
>> your consolidation with the _A_ double-spends to reduce the # of bytes=
=20
>> used per=20
>> full-rbf double-spend.=20
>>
>>
>> # TRUC/V3 Creates a Free Relay Attack=20
>>
>> I'll leave the details of this as a homework problem. But obviously, the=
=20
>> introduction of TRUC/V3 transactions *itself* creates a free relay attac=
k=20
>> very=20
>> similar to the above! Just like full-RBF, not all miners will mine V3=20
>> transactions. So you can do the exact same type of attack by taking=20
>> advantage=20
>> of this difference in mining policy.=20
>>
>> --=20
>> https://petertodd.org 'peter'[:-1]@petertodd.org=20
>>
>
--=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/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.com.
------=_Part_278079_2093069652.1721433412057
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi /dev/fd0<br /><br />> The last comment in the pull request suggests o=
pening a new pull request to enable full RBF by default, referencing the on=
e closed due to off-topic comments.<br /><br />I'm interested if you can pr=
opose a formal or mathematical definition of what constitute<br />an in-top=
ic of off-topic comments on a matters like full RBF, which has been controv=
ersial<br />for like a decade. I can only think such definition could make =
future conversations about<br />the boundaries of what is in / off bitcoin =
engineering topic more objective.<br /><br />> It seems that you are the=
one trying to politicize this issue.<br /><br />Let's be realistic on the =
state of bitcoin core security issues handling in the recent words of<br />=
a group of some active contributors:<br /><br />"The project has historical=
ly done a poor job at publicly disclosing security-critical bugs, whether<b=
r />externally reported or found by contributors. This has led to a situati=
on where a lot of users perceive<br />Bitcoin Core as never having bugs. Th=
is perception is dangerous and, unfortunately, not accurate." [0].<br /><br=
/>[0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w<br /><br />Agai=
n, I'm interested if you can propose a formal or mathematical definition of=
what constitute<br />a reasonable bitcoin core vulnerability handling poli=
cy and that way give more ground on qualifying<br />if a present situation =
is falling out of this reasonable guidelines and that can be qualified more=
<br />objectively as "politics".<br /><br />I think we have a mailing list=
to favorize textual long format and encourage a more self-reflexive<br />m=
ode of reasoning in the conduct of bitcoin engineering discussions. I belie=
ve comments not bringing<br />new factual information or pointing to past e=
xperiences or concrete piece of information are better<br />left to twitter=
/ nostr / reddit, whatever other communication channel where the scientifi=
c and<br />ethics of conversation standards are less stringent.<br /><br />=
All that said, I'm thinking to agree that the usage of all political rhetho=
ric is a fallacy better<br />left for expressions on other communication ch=
annels and this is note wise to bundle it with novel<br />technical informa=
tion, as from the outset it does not favor to concentrate the discussion on=
the fact<br />and logical reasoning themselves. Even more, political rheto=
ric very easily downgrade in moralistic<br />contest among protagonists on =
who has the monopole of the good / truth. Somehow bitcoin is beyond<br />go=
od and evil (-- under some long-term and abstract perspective).<br /><br />=
Best,<br />Antoine<br />ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb959=
4e96d57336d603556a8fdab<br /><div class=3D"gmail_quote"><div dir=3D"auto" c=
lass=3D"gmail_attr">Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev=
/fd0 a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">Hi Peter,<br><br>>=C2=A0I didn't get a substantive<br>&=
gt; response from Bitcoin Core, other than Core closing the my pull-req ena=
bling<br>> full-RBF by default that would fix this specific vulnerabilit=
y.<br><br>
The last comment in the pull request suggests opening a new pull request to=
enable full RBF by default, referencing the one closed due to off-topic co=
mments.
<div><br></div><div>>=C2=A0But read on, this is quite an odd case of Cor=
e politics, and the story is not<br>> as simple as Core refusing to fix =
a vulnerability.</div><div><br></div><div>
It seems that you are the one trying to politicize this issue.
</div><div><br></div><div>/dev/fd0</div><div>floppy disk guy<br><br></div><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursda=
y, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"># Summary
<br>
<br>This is a public disclosure of a vulnerability that I previously disclo=
sed to
<br>the bitcoin-security mailing list. It's an easy vulnerability to fi=
x. Although
<br>as with other "free" relay attacks I've disclosed, I didn=
't get a substantive
<br>response from Bitcoin Core, other than Core closing the my pull-req ena=
bling
<br>full-RBF by default that would fix this specific vulnerability.
<br>
<br>But read on, this is quite an odd case of Core politics, and the story =
is not
<br>as simple as Core refusing to fix a vulnerability. Also, I've inclu=
ding a fun
<br>homework problem at the end: figure out how TRUC/V3 transactions itself=
creates
<br>a "free" relay attack.
<br>
<br>
<br># Background
<br>
<br>This is just one of a few "free" relay attacks that I have re=
cently disclosed,
<br>including, but not limited to:
<br>
<br> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2=
024
<br> <a href=3D"https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg" re=
l=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dfr&q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV=
hg&source=3Dgmail&ust=3D1721519733686000&usg=3DAOvVaw1JWK1zwQNT=
_aXhRWKMfLVp">https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg</a>
<br>
<br> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences"=
; - Mar 31st 2024
<br> <a href=3D"https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo" re=
l=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dfr&q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX=
qo&source=3Dgmail&ust=3D1721519733686000&usg=3DAOvVaw2vw2Qd9rA4=
gYYajaUPKHoQ">https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo</a>
<br>
<br>The term "free relay attack" simply refers to any mechanism w=
here transaction
<br>data can be broadcast at unusually low cost; the "free" in &q=
uot;free relay" is a
<br>misnomer as all these attacks do in fact have some cost.
<br>
<br>This particular attack isn't significantly different than the other=
attacks
<br>I've disclosed. With one important exception: unlike those other at=
tacks,
<br>fixing this particular attack would be quite easy, by enabling full-rbf=
by
<br>default. So I disclosed it to the bitcoin-security mailing list as a te=
st: does
<br>Bitcoin Core actually care about free relay attacks? My hypothesis is t=
hat Core
<br>does not, as they know full well that "free" relay is an unav=
oidable problem;
<br>I've received absolutely no feedback from any Bitcoin Core members =
for the
<br>other disclosed attacks, beyond achow using my disclosure of the RBF Ru=
le #6
<br>attack as an excuse to remove me from the bitcoin-security mailing list=
.
<br>
<br>The fact that Core doesn't actually care about "free" rel=
ay attacks is relevant
<br>to TRUC/V3 Transactions. As per BIP-431:
<br>
<br> "The primary problem with [RBFR proposals] is the potential fo=
r free relay and DDoS attacks.
<br>
<br> Removing Rule 3 and 4 in general would allow free relay [27]."
<br> <a href=3D"https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e=
2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_=
by_feerate" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoin/bips/blob=
/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content=
-Alternatives_replace_by_feerate&source=3Dgmail&ust=3D1721519733686=
000&usg=3DAOvVaw1tx5cfYn8zpwIjDSfRR5M8">https://github.com/bitcoin/bips=
/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-cont=
ent-Alternatives_replace_by_feerate</a>
<br>
<br>I believe the authors of that BIP are fully aware of the fact that &quo=
t;free" relay
<br>is an unavoidable problem, making their rational for TRUC/V3 bogus, and=
don't
<br>want to admit that they've wasted a large amount of engineering tim=
e on a bad
<br>proposal. I will be submitting a pull-req to get BIP-431 corrected, as =
the many
<br>"free" relay attacks I've disclosed clearly show that cla=
iming RBFR would
<br>"allow" free relay is simply not true.
<br>
<br>Notably, full-RBF is _itself_ a transaction pinning fix for many use-ca=
ses;
<br>part of the TRUC/V3 standard is to force full-RBF behavior for V3 trans=
actions.
<br>So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a se=
cond
<br>way, and TRUC/V3 proponents were the ones who tried to get the full-RBF=
option
<br>removed from Core in the first place. If not for this dumb bit of Core
<br>politics, I'm sure my year-old pull-req to enable full-RBF by defau=
lt would
<br>have been merged many months ago, as almost all hashpower has adopted f=
ull-RBF
<br>making objections based on "zeroconf" absurd.
<br>
<br>
<br># The Attack
<br>
<br>If you're a competent Bitcoin engineer, familiar with how mempools =
work, you've
<br>probably figured it out already based on the title: obviously, if a hig=
h
<br>percentage of miners are adopting a policy that Bitcoin Core nodes are =
not, you
<br>can cheaply consume transaction relay bandwidth by simply relaying tran=
sations
<br>that miners are rejecting.
<br>
<br>Specifically, do the following:
<br>
<br>1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
<br>2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
<br>3. Spend the outputs of A in a large, low fee-rate, transaction B with =
BIP-125
<br> opt-in enabled. ~100% of miners will reject B, as it spends an input=
not in
<br> their mempools. However Bitcoin Core nodes will waste bandwidth prop=
agating
<br> B.
<br>4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will=
waste
<br> bandwidth propagating Bn's that ~100% of miners are ignoring.
<br>5. Double-spend A2 to recover your funds and do it all over again (or i=
f A2 had
<br> a high enough fee-rate, just wait for it to be mined).
<br>
<br>The cost to relay each B transaction depends on the fee-rate of B. Sinc=
e
<br>Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-=
rate is
<br>typically well below the economic fee-rate required for miners to actua=
lly mine
<br>a transaction; Core accepts transactions that are uneconomical for mine=
rs to
<br>mine for the forseeable future.
<br>
<br>For example, at the moment typical mempools require transactions to pay=
at
<br>least 1sat/vB, while there are hundreds of MvB worth of transactions pa=
ying
<br>4sat/vB, the minimum economical fee-rate. Thus, transactions paying les=
s than
<br>4sat/VB are extremely unlikely to get mined in the nearish future.
<br>
<br>Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v=
B would
<br>have almost zero cost as the probability of those transactions getting =
mined is
<br>nearly zero. This is true _regardless_ of what % of miners are mining f=
ull-RBF!
<br>As long as you can get at least one miner to mine the A double-spend, t=
he
<br>attack only costs what it cost to get A mined.
<br>
<br>If B's are broadcast at a higher fee-rate than the minimum economic=
al fee-rate,
<br>then the % of full-RBF miners matters. For example, if only 99% of mine=
rs mine
<br>full-RBF, the chance of a B transaction getting mined per block is abou=
t 1%, so
<br>the amortized cost of broadcasting B is about 1% of whatever total fee =
the
<br>highest fee-rate variant of B pays.
<br>
<br>For an attacker who does not need any B to be broadcast, the cost savin=
gs to
<br>use of relay bandwidth is approximately the ratio of the difference in =
size
<br>between B and and A. With a maximum standard transaction size of 100KvB=
, or
<br>400KB serialized size, this ratio is on the order of 5000:1, times the =
total
<br>number of B variants broadcast, and the % chance of each B being mined;=
it's a
<br>few orders of magnitude.
<br>
<br>Of course, as mentioned above, this is just one of *many* "free&qu=
ot; relay attacks,
<br>so fixing this particular issue doesn't change much.
<br>
<br>
<br># Attackers Who Benefit From B Getting Mined
<br>
<br>Some attackers actually need B to get mined. For example, imagine an ex=
change
<br>who needs to do large consolidation transactions. They could use this a=
ttack
<br>(and some attacks like it) as a way to goad users and miners into minin=
g
<br>consolidation transactions for them at low cost. In this variant of the=
attack,
<br>the attacker would pad the size of B with consolidation spends that the=
y needed
<br>to do anyway. Someone who tried to stop the attack by getting B mined (=
eg via
<br><a href=3D"http://mempool.space" rel=3D"nofollow" target=3D"_blank" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttp://memp=
ool.space&source=3Dgmail&ust=3D1721519733686000&usg=3DAOvVaw1bI=
3qp0BlvuT04MBTGkzgR">mempool.space</a>'s transaction accellerator) woul=
d simply be paying the attacker's
<br>fees for them.
<br>
<br>Obviously, this strategy is only relevant for B's below the economi=
c fee-rate.
<br>However, the weaker version of this strategy is to parallize the attack=
, and do
<br>your consolidation with the _A_ double-spends to reduce the # of bytes =
used per
<br>full-rbf double-spend.
<br>
<br>
<br># TRUC/V3 Creates a Free Relay Attack
<br>
<br>I'll leave the details of this as a homework problem. But obviously=
, the
<br>introduction of TRUC/V3 transactions *itself* creates a free relay atta=
ck very
<br>similar to the above! Just like full-RBF, not all miners will mine V3
<br>transactions. So you can do the exact same type of attack by taking adv=
antage
<br>of this difference in mining policy.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" rel=3D"nofollow" target=3D"_blank" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://pe=
tertodd.org&source=3Dgmail&ust=3D1721519733686000&usg=3DAOvVaw3=
SiNGxs3N4NRh9AizL-oLu">https://petertodd.org</a> 'peter'[:-1]@<a hr=
ef=3D"http://petertodd.org" rel=3D"nofollow" target=3D"_blank" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttp://petertodd.org=
&source=3Dgmail&ust=3D1721519733686000&usg=3DAOvVaw1TCiAKw5MRpR=
pgpbaLIm1j">petertodd.org</a>
<br></blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.com</a>.=
<br />
------=_Part_278079_2093069652.1721433412057--
------=_Part_278078_1820075485.1721433412057--