Delivery-date: Thu, 18 Jul 2024 16:10:37 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUaGh-0006xo-TI for bitcoindev@gnusha.org; Thu, 18 Jul 2024 16:10:37 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e03a7949504sf2972060276.2 for ; Thu, 18 Jul 2024 16:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721344229; x=1721949029; 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=AVXeBAKXonuTmoSTfA1MBcEu2SDnbU5WDezVEhyEIQY=; b=uiYZX5GU3LmQFwAjJbjb2S+x6crxLVfc0AY5NHymGlwwgagMo40zMDtopGcXK9aCpF 5GgClmw9FUCH7ALNLbSSijXgMGknaxCcfIELcSFj81KXVd6AT+kBr+W2X1RkwLF8lyMU EgMkc/gReAqwZRWnlzQZOQBHSJ9P8w09nj3jItn08laShr+5HLccb3OSGiRM9Q2KAR39 V5icA/v4C5xkhnMC+7nYbshGc/yFvQ05UgTWEncwAC48qibrG0WqS8CtCW89uxK/KriQ x/i2+BkI9jHEqG43bf9yZHtGCV67bA5PfLqTsobxmbyAWjTw6rmoWhAMtHJV8njqWFfw kkNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721344229; x=1721949029; 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=AVXeBAKXonuTmoSTfA1MBcEu2SDnbU5WDezVEhyEIQY=; b=lR4fgXJWvDCcPdLqXiZX2mkpyUu1VEy9/Gyfq2DiRYDupSEIQI645X0CKyID8K5jHJ pvSPUrli7W6km8asCj2j1dyr4M0342Dl2EtORwVKZIlTqrcneRQu0/aWE7nI2dyX7XQl bdbz6dSJMVZAueHNY5iuwAF6yEhrTRSS/p7dERfo9THacxMTpjFc7OfEIPVDyPPjU44b DGutQtCHJGkcqwQjPPjkLFudUv9pYT7F4ao8PekI2m9dGhDfUQVSigMx0CndE4NlU9Jo ULnhkbZGeaFjn8h0/QCd6Icd+GlYj+18KKx9jvUTn9g5jc7vrArxdSQUyL6DMq8oeQcA RwDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721344229; x=1721949029; 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=AVXeBAKXonuTmoSTfA1MBcEu2SDnbU5WDezVEhyEIQY=; b=orx/KC2snAdTdEc9JCQRrWsSIDYXqs9mtFZO1ss0hRG0PPsRQlorZwkotaHoZsyEFI bhIsINlszFf5EITBLNz4DGhduhZ0ZjmkPrarBxDl84itfktbHY4gDXlJVcYZ5ZgyvtpU iDVD7kztC530UoigyuuWYHxBTfOQi3xDO5jozEcjwnHup+nJDmV/kOe3pMTBsqEuy5JV vPsIZj9Egmj9Gy2OV/3Ip8q6Hb78Y+Zi+SwVLQ2h/5f9FaSMJ3+oTFTI93YtymxjiTIv 4woZz5nhbgxt3VuT9NPZfKJ5HfkAh9EtkIlFdgeuXtW1QUNX2F2cght0zP8F+Q22zpP8 ncNw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXGm/Fu9P2IAs5dQYsYmxViA47talitIpvpfnpSaJUxf7QDmegArQ/G8N1cw7R8HNz1Lo1DoThZH296bYYMXbFCmT+4y9A= X-Gm-Message-State: AOJu0YwOKy4rSOwF1WLq7NwisZREzLDkR2SFQ6aoPSI2qj8TonZWv4hc DmhxSlI1qdiLdyhRIGmmsskBLe0SZ6JZFoTnfRw6VMogQ6wXTwKR X-Google-Smtp-Source: AGHT+IESs/4IusIq7BGBudYZzLNpR3rEb49ClF43QVO2nOozoGu1yc6HFkxn2l0OWX6wfSQvg7xe+Q== X-Received: by 2002:a05:6902:154e:b0:dff:1020:6f31 with SMTP id 3f1490d57ef6-e0860ac62bamr415518276.45.1721344229258; Thu, 18 Jul 2024 16:10:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:690d:0:b0:e03:37d1:efbd with SMTP id 3f1490d57ef6-e05fdb82a52ls2472860276.2.-pod-prod-04-us; Thu, 18 Jul 2024 16:10:27 -0700 (PDT) X-Received: by 2002:a05:690c:8:b0:62f:22cd:7082 with SMTP id 00721157ae682-666038f62fcmr3181827b3.5.1721344227112; Thu, 18 Jul 2024 16:10:27 -0700 (PDT) Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18ams7b3; Thu, 18 Jul 2024 16:04:48 -0700 (PDT) X-Received: by 2002:a05:690c:fd1:b0:667:8a45:d0f9 with SMTP id 00721157ae682-6678a45ec04mr1671177b3.0.1721343887609; Thu, 18 Jul 2024 16:04:47 -0700 (PDT) Date: Thu, 18 Jul 2024 16:04:47 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> In-Reply-To: References: 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_227714_1014636734.1721343887379" 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_227714_1014636734.1721343887379 Content-Type: multipart/alternative; boundary="----=_Part_227715_898393524.1721343887379" ------=_Part_227715_898393524.1721343887379 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for the sharing of information about "free relay" attack. I have one question I'm curious to know the answer which is how much time= =20 have been left the private report of this issue to the bitcoin-security mailing= =20 list and the public disclosure. With still in mind the conversation that happens= =20 on the other thread few months ago, and unless emergency I think it's good to= =20 give few weeks of leeway for a vendor team to answer substantially [0]. Beyond, if what you're saying is correct, in your administrative removal=20 from the bitcoin-security mailing list by achow, I'm curious in achow explaining in= =20 public its rational in this unexpected decision and what did happen in its own=20 words. I respect achow as a bitcoin core maintainer from years of collaboration on= =20 the repository and achow is one of the few bitcoin professionals I still=20 reasonably trust in matters of security report and coordinated mitigation in this=20 space. All that said, with the new information you're sharing and without achow's= =20 substantial answer, it let me ponder if achow is still worthy that it's someome with=20 whom I'll share in the future security-sensitive related information to bitcoin core and=20 the base-layer robustnes. After all, the bitcoin-security mailing list is just a=20 communication endpoint and there is no adamant ethical rule abstraining a security researcher to= =20 diligently=20 report issues. About V3 / TRUC, I must say that originally few years ago when we=20 discovered all the transaction pinning issues affecting lightning funds security in a strict= =20 sense, I was among the people advocating the design and deployment of new policy rules= =20 as a way to migitate the pinnings concerns [1]. I must say with more implementation=20 experiences of policy rules, new discovery like replacement cycling issues and reasoning= =20 on the mining game-theory of policy rules, I've come incredebly skeptical that V3 / TRUC= =20 is the "right way" to mitigate pinnings vectors. At the very best, in my opinion it's a= =20 "poor's man band aid"'s in waiting that someone design something better. This wouldn't bet the first time that less-than-perfect p2p / mempools=20 extensions are introduced in bitcoin (e.g bip37) and with time more and more folks realize= =20 that effectively the design has more and more apparent weakeness with time. About the new attack itself, which I beleive holds at first read, I think= =20 your explanation can benefit to layout more the mining topology configutation and policy=20 default which makes the free-relay attack exploitable and explain step-by-step how the spend=20 and double-spend are propagate in the transaction-relay network. In my understanding, the attack efficiency varies widely in function of the= =20 hashrate ressources of the miner getting the high-feerate double-spend A2 transaction. I think= =20 higher are the hashrate ressources, lower would have been the transaction B (re)-broadcast=20 bandwidth waste. I don't think the exploitation example with an exchange you're giving is=20 the more speaking adversarial example, however I believe it's an interesting building block= =20 for other types of attacks, which is worthy of research. On the TRUC / V3 creating new attacks vectors, this will all dependent if= =20 the miners adopt this change and if they estimate it's maximzing their mining income revenue= =20 in average, it's a one line of code to disable currently (L134 in `src/policy/policy.h`=20 tweaking the 3 back to 2). Best, Antoine ots hash: d40d371e725626589feaf439dcc301af9ae287f5dc06eb26155b95fcd608438e [0] I checked my own archive after writing this email on the "free relay"= =20 thread [2]. In fact even about time-dilation attack, I gave more than 2 weeks for the lightning= =20 maintainers to do something, if they wished so before to do a full-disclosure. 2 weeks is a= =20 reasonable heuristic. [1] See=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.ht= ml [2] https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg Le jeudi 18 juillet 2024 =C3=A0 17:04:26 UTC+1, Peter Todd a =C3=A9crit : > # Summary > > This is a public disclosure of a vulnerability that I previously disclose= d=20 > to > the bitcoin-security mailing list. It's an easy vulnerability to fix.=20 > Although > as with other "free" relay attacks I've disclosed, I didn't get a=20 > 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. > > But read on, this is quite an odd case of Core politics, and the story is= =20 > not > as simple as Core refusing to fix a vulnerability. Also, I've including a= =20 > fun > homework problem at the end: figure out how TRUC/V3 transactions itself= =20 > creates > a "free" relay attack. > > > # Background > > This is just one of a few "free" relay attacks that I have recently=20 > disclosed, > including, but not limited to: > > "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024 > https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg > > "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 202= 4 > https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo > > The term "free relay attack" simply refers to any mechanism where=20 > transaction > data can be broadcast at unusually low cost; the "free" in "free relay" i= s=20 > a > misnomer as all these attacks do in fact have some cost. > > This particular attack isn't significantly different than the other attac= ks > I've disclosed. With one important exception: unlike those other attacks, > fixing this particular attack would be quite easy, by enabling full-rbf b= y > default. So I disclosed it to the bitcoin-security mailing list as a test= :=20 > does > Bitcoin Core actually care about free relay attacks? My hypothesis is tha= t=20 > Core > does not, as they know full well that "free" relay is an unavoidable=20 > problem; > I've received absolutely no feedback from any Bitcoin Core members for th= e > other disclosed attacks, beyond achow using my disclosure of the RBF Rule= =20 > #6 > attack as an excuse to remove me from the bitcoin-security mailing list. > > The fact that Core doesn't actually care about "free" relay attacks is=20 > relevant > to TRUC/V3 Transactions. As per BIP-431: > > "The primary problem with [RBFR proposals] is the potential for free rela= y=20 > and DDoS attacks. > > Removing Rule 3 and 4 in general would allow free relay [27]." > > https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a42= 8aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate > > I believe the authors of that BIP are fully aware of the fact that "free"= =20 > relay > is an unavoidable problem, making their rational for TRUC/V3 bogus, and= =20 > don't > want to admit that they've wasted a large amount of engineering time on a= =20 > bad > proposal. I will be submitting a pull-req to get BIP-431 corrected, as th= e=20 > many > "free" relay attacks I've disclosed clearly show that claiming RBFR would > "allow" free relay is simply not true. > > Notably, full-RBF is _itself_ a transaction pinning fix for many use-case= s; > part of the TRUC/V3 standard is to force full-RBF behavior for V3=20 > transactions. > So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a seco= nd > way, and TRUC/V3 proponents were the ones who tried to get the full-RBF= =20 > 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 default wou= ld > have been merged many months ago, as almost all hashpower has adopted=20 > full-RBF > making objections based on "zeroconf" absurd. > > > # The Attack > > If you're a competent Bitcoin engineer, familiar with how mempools work,= =20 > you've > probably figured it out already based on the title: obviously, if a high > percentage of miners are adopting a policy that Bitcoin Core nodes are=20 > not, you > can cheaply consume transaction relay bandwidth by simply relaying=20 > transations > 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=20 > 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 propagati= ng > B. > 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will= =20 > 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 if= =20 > 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. Since > Bitcoin Core defaults to a fairly large mempool, the minimum relay=20 > fee-rate is > typically well below the economic fee-rate required for miners to actuall= y=20 > mine > a transaction; Core accepts transactions that are uneconomical for miners= =20 > to > mine for the forseeable future. > > For example, at the moment typical mempools require transactions to pay a= t > least 1sat/vB, while there are hundreds of MvB worth of transactions payi= ng > 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less= =20 > than > 4sat/VB are extremely unlikely to get mined in the nearish future. > > Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB= =20 > would > have almost zero cost as the probability of those transactions getting=20 > mined is > nearly zero. This is true _regardless_ of what % of miners are mining=20 > full-RBF! > As long as you can get at least one miner to mine the A double-spend, the > attack only costs what it cost to get A mined. > > If B's are broadcast at a higher fee-rate than the minimum economical=20 > fee-rate, > then the % of full-RBF miners matters. For example, if only 99% of miners= =20 > mine > full-RBF, the chance of a B transaction getting mined per block is about= =20 > 1%, so > the amortized cost of broadcasting B is about 1% of whatever total fee th= e > highest fee-rate variant of B pays. > > For an attacker who does not need any B to be broadcast, the cost savings= =20 > to > use of relay bandwidth is approximately the ratio of the difference in si= ze > 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=20 > total > number of B variants broadcast, and the % chance of each B being mined;= =20 > it's a > few orders of magnitude. > > Of course, as mentioned above, this is just one of *many* "free" relay=20 > 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=20 > exchange > who needs to do large consolidation transactions. They could use this=20 > attack > (and some attacks like it) as a way to goad users and miners into mining > consolidation transactions for them at low cost. In this variant of the= =20 > attack, > the attacker would pad the size of B with consolidation spends that they= =20 > needed > to do anyway. Someone who tried to stop the attack by getting B mined (eg= =20 > via > mempool.space's transaction accellerator) would simply be paying the=20 > attacker's > fees for them. > > Obviously, this strategy is only relevant for B's below the economic=20 > fee-rate. > However, the weaker version of this strategy is to parallize the attack,= =20 > and do > your consolidation with the _A_ double-spends to reduce the # of bytes=20 > 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 attack= =20 > 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=20 > advantage > of this difference in mining policy. > > --=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/18fc443d-c347-4a84-94fe-81308ae20b76n%40googlegroups.com. ------=_Part_227715_898393524.1721343887379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter,

Thanks for the sharing of information about "free rela= y" attack.

I have one question I'm curious to know the answer wh= ich is how much time have
been left the private report of this issue t= o the bitcoin-security mailing list
and the public disclosure. With st= ill in mind the conversation that happens on
the other thread few mont= hs ago, and unless emergency I think it's good to give
few weeks of le= eway for a vendor team to answer substantially [0].

Beyond, if w= hat you're saying is correct, in your administrative removal from the
= bitcoin-security mailing list by achow, I'm curious in achow explaining in = public
its rational in this unexpected decision and what did happen in= its own words.
I respect achow as a bitcoin core maintainer from year= s of collaboration on the
repository and achow is one of the few bitco= in professionals I still reasonably
trust in matters of security repor= t and coordinated mitigation in this space.

All that said, with = the new information you're sharing and without achow's substantial
ans= wer, it let me ponder if achow is still worthy that it's someome with whom = I'll share
in the future security-sensitive related information to bit= coin core and the base-layer
robustnes. After all, the bitcoin-securit= y mailing list is just a communication endpoint
and there is no adaman= t ethical rule abstraining a security researcher to diligently
report= issues.

About V3 / TRUC, I must say that originally few years a= go when we discovered all the
transaction pinning issues affecting lig= htning funds security in a strict sense, I was
among the people advoca= ting the design and deployment of new policy rules as a way to
migitat= e the pinnings concerns [1]. I must say with more implementation experience= s of
policy rules, new discovery like replacement cycling issues and r= easoning on the mining
game-theory of policy rules, I've come incredeb= ly skeptical that V3 / TRUC is the "right
way" to mitigate pinnings ve= ctors. At the very best, in my opinion it's a "poor's man band
aid"'s = in waiting that someone design something better.

This wouldn't b= et the first time that less-than-perfect p2p / mempools extensions are
introduced in bitcoin (e.g bip37) and with time more and more folks realiz= e that effectively
the design has more and more apparent weakeness wit= h time.

About the new attack itself, which I beleive holds at fi= rst read, I think your explanation
can benefit to layout more the mini= ng topology configutation and policy default which makes
the free-rela= y attack exploitable and explain step-by-step how the spend and double-spen= d
are propagate in the transaction-relay network.

In my und= erstanding, the attack efficiency varies widely in function of the hashrate= ressources
of the miner getting the high-feerate double-spend A2 tran= saction. I think higher are the hashrate
ressources, lower would have = been the transaction B (re)-broadcast bandwidth waste.

I don't t= hink the exploitation example with an exchange you're giving is the more sp= eaking
adversarial example, however I believe it's an interesting buil= ding block for other types of
attacks, which is worthy of research.
On the TRUC / V3 creating new attacks vectors, this will all depen= dent if the miners adopt
this change and if they estimate it's maximzi= ng their mining income revenue in average, it's
a one line of code to = disable currently (L134 in `src/policy/policy.h` tweaking the 3 back to 2).=

Best,
Antoine
ots hash: d40d371e725626589feaf439dcc30= 1af9ae287f5dc06eb26155b95fcd608438e

[0] I checked my own archive= after writing this email on the "free relay" thread [2]. In fact
even= about time-dilation attack, I gave more than 2 weeks for the lightning mai= ntainers to do
something, if they wished so before to do a full-disclo= sure. 2 weeks is a reasonable heuristic.

[1] See https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html

[2]=C2=A0https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
Le= jeudi 18 juillet 2024 =C3=A0 17:04:26 UTC+1, Peter Todd a =C3=A9crit=C2=A0= :
# 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/18fc443d-c347-4a84-94fe-81308ae20b76n%40googlegroups.com.=
------=_Part_227715_898393524.1721343887379-- ------=_Part_227714_1014636734.1721343887379--