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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com> In-Reply-To: <18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com> References: <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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

> 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.

I'm interested if you can pr= opose a formal or mathematical definition of what constitute
an in-top= ic of off-topic comments on a matters like full RBF, which has been controv= ersial
for like a decade. I can only think such definition could make = future 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 the recent words of
= a group of some active contributors:

"The project has historical= ly done a poor job at publicly disclosing security-critical bugs, whetherexternally reported or found by contributors. This has led to a situati= on where a lot of users perceive
Bitcoin Core as never having bugs. Th= is perception is dangerous and, unfortunately, not accurate." [0].
[0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Agai= n, I'm interested if you can propose a formal or mathematical definition of= what constitute
a reasonable bitcoin core vulnerability handling poli= cy and that way give more ground on qualifying
if a present situation = is falling out of this reasonable guidelines and that can be qualified more=
objectively as "politics".

I think we have a mailing list= to favorize textual long format and encourage a more self-reflexive
m= ode of reasoning in the conduct of bitcoin engineering discussions. I belie= ve comments not bringing
new factual information or pointing to past e= xperiences or concrete piece of information are better
left to twitter= / nostr / reddit, whatever other communication channel where the scientifi= c and
ethics of conversation standards are less stringent.

= All that said, I'm thinking to agree that the usage of all political rhetho= ric is a fallacy better
left for expressions on other communication ch= annels and this is note wise to bundle it with novel
technical informa= tion, as from the outset it does not favor to concentrate the discussion on= the fact
and logical reasoning themselves. Even more, political rheto= ric very easily downgrade in moralistic
contest among protagonists on = who has the monopole of the good / truth. Somehow bitcoin is beyond
go= od and evil (-- under some long-term and abstract perspective).

= Best,
Antoine
ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb959= 4e96d57336d603556a8fdab
Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev= /fd0 a =C3=A9crit=C2=A0:
Hi Peter,

>=C2=A0I didn't get a substantive
&= gt; response from Bitcoin Core, other than Core closing the my pull-req ena= bling
> full-RBF by default that would fix this specific vulnerabilit= y.

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.

>=C2=A0But read on, this is quite an odd case of Cor= e politics, and the story is not
> as simple as Core refusing to fix = a vulnerability.

It seems that you are the one trying to politicize this issue.

/dev/fd0
floppy disk guy

<= div class=3D"gmail_quote">
On Thursda= y, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:
# Summary

This is a public disclosure of a vulnerability that I previously disclo= sed to
the bitcoin-security mailing list. It's an easy vulnerability to fi= x. Although
as with other "free" relay attacks I've disclosed, I didn= 't get a substantive
response from Bitcoin Core, other than Core closing the my pull-req ena= bling
full-RBF by default that would fix this specific vulnerability.

But read on, this is quite an odd case of Core politics, and the story = is not
as simple as Core refusing to fix a vulnerability. Also, I've inclu= ding a fun
homework problem at the end: figure out how TRUC/V3 transactions itself= creates
a "free" relay attack.


# Background

This is just one of a few "free" relay attacks that I have re= cently disclosed,
including, but not limited to:

"A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2= 024
https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg

"A Free-Relay Attack Exploiting Min-Relay-Fee Differences"= ; - Mar 31st 2024
https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo

The term "free relay attack" simply refers to any mechanism w= here transaction
data can be broadcast at unusually low cost; the "free" in &q= uot;free relay" is a
misnomer as all these attacks do in fact have some cost.

This particular attack isn't significantly different than the other= attacks
I've disclosed. With one important exception: unlike those other at= tacks,
fixing this particular attack would be quite easy, by enabling full-rbf= by
default. So I disclosed it to the bitcoin-security mailing list as a te= st: does
Bitcoin Core actually care about free relay attacks? My hypothesis is t= hat Core
does not, as they know full well that "free" relay is an unav= oidable problem;
I've received absolutely no feedback from any Bitcoin Core members = for the
other disclosed attacks, beyond achow using my disclosure of the RBF Ru= le #6
attack as an excuse to remove me from the bitcoin-security mailing list= .

The fact that Core doesn't actually care about "free" rel= ay attacks is relevant
to TRUC/V3 Transactions. As per BIP-431:

"The primary problem with [RBFR proposals] is the potential fo= r free relay and DDoS attacks.

Removing Rule 3 and 4 in general would allow free relay [27]."
https://github.com/bitcoin/bips= /blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-cont= ent-Alternatives_replace_by_feerate

I believe the authors of that BIP are fully aware of the fact that &quo= t;free" relay
is an unavoidable problem, making their rational for TRUC/V3 bogus, and= don't
want to admit that they've wasted a large amount of engineering tim= e on a bad
proposal. I will be submitting a pull-req to get BIP-431 corrected, as = the many
"free" relay attacks I've disclosed clearly show that cla= iming RBFR would
"allow" free relay is simply not true.

Notably, full-RBF is _itself_ a transaction pinning fix for many use-ca= ses;
part of the TRUC/V3 standard is to force full-RBF behavior for V3 trans= actions.
So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a se= cond
way, and TRUC/V3 proponents were the ones who tried to get the full-RBF= option
removed from Core in the first place. If not for this dumb bit of Core
politics, I'm sure my year-old pull-req to enable full-RBF by defau= lt would
have been merged many months ago, as almost all hashpower has adopted f= ull-RBF
making objections based on "zeroconf" absurd.


# The Attack

If you're a competent Bitcoin engineer, familiar with how mempools = work, you've
probably figured it out already based on the title: obviously, if a hig= h
percentage of miners are adopting a policy that Bitcoin Core nodes are = not, you
can cheaply consume transaction relay bandwidth by simply relaying tran= sations
that miners are rejecting.

Specifically, do the following:

1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
3. Spend the outputs of A in a large, low fee-rate, transaction B with = BIP-125
opt-in enabled. ~100% of miners will reject B, as it spends an input= not in
their mempools. However Bitcoin Core nodes will waste bandwidth prop= agating
B.
4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will= waste
bandwidth propagating Bn's that ~100% of miners are ignoring.
5. Double-spend A2 to recover your funds and do it all over again (or i= f A2 had
a high enough fee-rate, just wait for it to be mined).

The cost to relay each B transaction depends on the fee-rate of B. Sinc= e
Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-= rate is
typically well below the economic fee-rate required for miners to actua= lly mine
a transaction; Core accepts transactions that are uneconomical for mine= rs to
mine for the forseeable future.

For example, at the moment typical mempools require transactions to pay= at
least 1sat/vB, while there are hundreds of MvB worth of transactions pa= ying
4sat/vB, the minimum economical fee-rate. Thus, transactions paying les= s than
4sat/VB are extremely unlikely to get mined in the nearish future.

Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v= B would
have almost zero cost as the probability of those transactions getting = mined is
nearly zero. This is true _regardless_ of what % of miners are mining f= ull-RBF!
As long as you can get at least one miner to mine the A double-spend, t= he
attack only costs what it cost to get A mined.

If B's are broadcast at a higher fee-rate than the minimum economic= al fee-rate,
then the % of full-RBF miners matters. For example, if only 99% of mine= rs mine
full-RBF, the chance of a B transaction getting mined per block is abou= t 1%, so
the amortized cost of broadcasting B is about 1% of whatever total fee = the
highest fee-rate variant of B pays.

For an attacker who does not need any B to be broadcast, the cost savin= gs to
use of relay bandwidth is approximately the ratio of the difference in = size
between B and and A. With a maximum standard transaction size of 100KvB= , or
400KB serialized size, this ratio is on the order of 5000:1, times the = total
number of B variants broadcast, and the % chance of each B being mined;= it's a
few orders of magnitude.

Of course, as mentioned above, this is just one of *many* "free&qu= ot; relay attacks,
so fixing this particular issue doesn't change much.


# Attackers Who Benefit From B Getting Mined

Some attackers actually need B to get mined. For example, imagine an ex= change
who needs to do large consolidation transactions. They could use this a= ttack
(and some attacks like it) as a way to goad users and miners into minin= g
consolidation transactions for them at low cost. In this variant of the= attack,
the attacker would pad the size of B with consolidation spends that the= y needed
to do anyway. Someone who tried to stop the attack by getting B mined (= eg via
mempool.space's transaction accellerator) woul= d simply be paying the attacker's
fees for them.

Obviously, this strategy is only relevant for B's below the economi= c fee-rate.
However, the weaker version of this strategy is to parallize the attack= , and do
your consolidation with the _A_ double-spends to reduce the # of bytes = used per
full-rbf double-spend.


# TRUC/V3 Creates a Free Relay Attack

I'll leave the details of this as a homework problem. But obviously= , the
introduction of TRUC/V3 transactions *itself* creates a free relay atta= ck very
similar to the above! Just like full-RBF, not all miners will mine V3
transactions. So you can do the exact same type of attack by taking adv= antage
of this difference in mining policy.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.com.=
------=_Part_278079_2093069652.1721433412057-- ------=_Part_278078_1820075485.1721433412057--