path: root/0d/0314d14dbd9f9698f1dc399bd20c48ad1e75f1

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 <bitcoindev+bncBC3PT7FYWAMRBY6B422AMGQE3IIUITA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com>
In-Reply-To: <Zpk7EYgmlgPP3Y9D@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
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: <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_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,<br /><br />Thanks for the sharing of information about "free rela=
y" attack.<br /><br />I have one question I'm curious to know the answer wh=
ich is how much time have<br />been left the private report of this issue t=
o the bitcoin-security mailing list<br />and the public disclosure. With st=
ill in mind the conversation that happens on<br />the other thread few mont=
hs ago, and unless emergency I think it's good to give<br />few weeks of le=
eway for a vendor team to answer substantially [0].<br /><br />Beyond, if w=
hat you're saying is correct, in your administrative removal from the<br />=
bitcoin-security mailing list by achow, I'm curious in achow explaining in =
public<br />its rational in this unexpected decision and what did happen in=
 its own words.<br />I respect achow as a bitcoin core maintainer from year=
s of collaboration on the<br />repository and achow is one of the few bitco=
in professionals I still reasonably<br />trust in matters of security repor=
t and coordinated mitigation in this space.<br /><br />All that said, with =
the new information you're sharing and without achow's substantial<br />ans=
wer, it let me ponder if achow is still worthy that it's someome with whom =
I'll share<br />in the future security-sensitive related information to bit=
coin core and the base-layer<br />robustnes. After all, the bitcoin-securit=
y mailing list is just a communication endpoint<br />and there is no adaman=
t ethical rule abstraining a security researcher to diligently <br />report=
 issues.<br /><br />About V3 / TRUC, I must say that originally few years a=
go when we discovered all the<br />transaction pinning issues affecting lig=
htning funds security in a strict sense, I was<br />among the people advoca=
ting the design and deployment of new policy rules as a way to<br />migitat=
e the pinnings concerns [1]. I must say with more implementation experience=
s of<br />policy rules, new discovery like replacement cycling issues and r=
easoning on the mining<br />game-theory of policy rules, I've come incredeb=
ly skeptical that V3 / TRUC is the "right<br />way" to mitigate pinnings ve=
ctors. At the very best, in my opinion it's a "poor's man band<br />aid"'s =
in waiting that someone design something better.<br /><br />This wouldn't b=
et the first time that less-than-perfect p2p / mempools extensions are<br /=
>introduced in bitcoin (e.g bip37) and with time more and more folks realiz=
e that effectively<br />the design has more and more apparent weakeness wit=
h time.<br /><br />About the new attack itself, which I beleive holds at fi=
rst read, I think your explanation<br />can benefit to layout more the mini=
ng topology configutation and policy default which makes<br />the free-rela=
y attack exploitable and explain step-by-step how the spend and double-spen=
d<br />are propagate in the transaction-relay network.<br /><br />In my und=
erstanding, the attack efficiency varies widely in function of the hashrate=
 ressources<br />of the miner getting the high-feerate double-spend A2 tran=
saction. I think higher are the hashrate<br />ressources, lower would have =
been the transaction B (re)-broadcast bandwidth waste.<br /><br />I don't t=
hink the exploitation example with an exchange you're giving is the more sp=
eaking<br />adversarial example, however I believe it's an interesting buil=
ding block for other types of<br />attacks, which is worthy of research.<br=
 /><br />On the TRUC / V3 creating new attacks vectors, this will all depen=
dent if the miners adopt<br />this change and if they estimate it's maximzi=
ng their mining income revenue in average, it's<br />a one line of code to =
disable currently (L134 in `src/policy/policy.h` tweaking the 3 back to 2).=
<br /><br />Best,<br />Antoine<br />ots hash: d40d371e725626589feaf439dcc30=
1af9ae287f5dc06eb26155b95fcd608438e<br /><br />[0] I checked my own archive=
 after writing this email on the "free relay" thread [2]. In fact<br />even=
 about time-dilation attack, I gave more than 2 weeks for the lightning mai=
ntainers to do<br />something, if they wished so before to do a full-disclo=
sure. 2 weeks is a reasonable heuristic.<br /><br />[1] See https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html<div><br /></=
div><div>[2]=C2=A0https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg<br /=
></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le=
 jeudi 18 juillet 2024 =C3=A0 17:04:26 UTC+1, Peter Todd 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;"># Summary
<br>
<br>This is a public disclosure of a vulnerability that I previously disclo=
sed to
<br>the bitcoin-security mailing list. It&#39;s an easy vulnerability to fi=
x. Although
<br>as with other &quot;free&quot; relay attacks I&#39;ve disclosed, I didn=
&#39;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&#39;ve inclu=
ding a fun
<br>homework problem at the end: figure out how TRUC/V3 transactions itself=
 creates
<br>a &quot;free&quot; relay attack.
<br>
<br>
<br># Background
<br>
<br>This is just one of a few &quot;free&quot; relay attacks that I have re=
cently disclosed,
<br>including, but not limited to:
<br>
<br>    &quot;A Free-Relay Attack Exploiting RBF Rule #6&quot; - Mar 18th 2=
024
<br>    <a href=3D"https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV=
hg&amp;source=3Dgmail&amp;ust=3D1721430083533000&amp;usg=3DAOvVaw28pIvfydLe=
rmZuJr4Xteiu">https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg</a>
<br>
<br>    &quot;A Free-Relay Attack Exploiting Min-Relay-Fee Differences&quot=
; - Mar 31st 2024
<br>    <a href=3D"https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX=
qo&amp;source=3Dgmail&amp;ust=3D1721430083533000&amp;usg=3DAOvVaw2ciEmH2LtR=
H29UHsN69zTJ">https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo</a>
<br>
<br>The term &quot;free relay attack&quot; simply refers to any mechanism w=
here transaction
<br>data can be broadcast at unusually low cost; the &quot;free&quot; in &q=
uot;free relay&quot; is a
<br>misnomer as all these attacks do in fact have some cost.
<br>
<br>This particular attack isn&#39;t significantly different than the other=
 attacks
<br>I&#39;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 &quot;free&quot; relay is an unav=
oidable problem;
<br>I&#39;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&#39;t actually care about &quot;free&quot; rel=
ay attacks is relevant
<br>to TRUC/V3 Transactions. As per BIP-431:
<br>
<br>    &quot;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].&quot;
<br>    <a href=3D"https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e=
2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_=
by_feerate" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bips/blob=
/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content=
-Alternatives_replace_by_feerate&amp;source=3Dgmail&amp;ust=3D1721430083533=
000&amp;usg=3DAOvVaw05pNzVukzuXrQBB2ftKj_H">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&quot; relay
<br>is an unavoidable problem, making their rational for TRUC/V3 bogus, and=
 don&#39;t
<br>want to admit that they&#39;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>&quot;free&quot; relay attacks I&#39;ve disclosed clearly show that cla=
iming RBFR would
<br>&quot;allow&quot; 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&#39;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 &quot;zeroconf&quot; absurd.
<br>
<br>
<br># The Attack
<br>
<br>If you&#39;re a competent Bitcoin engineer, familiar with how mempools =
work, you&#39;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&#39;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&#39;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&#39;s a
<br>few orders of magnitude.
<br>
<br>Of course, as mentioned above, this is just one of *many* &quot;free&qu=
ot; relay attacks,
<br>so fixing this particular issue doesn&#39;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" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://memp=
ool.space&amp;source=3Dgmail&amp;ust=3D1721430083533000&amp;usg=3DAOvVaw3I3=
8uX9YFHZK8Dg2u_C1dQ">mempool.space</a>&#39;s transaction accellerator) woul=
d simply be paying the attacker&#39;s
<br>fees for them.
<br>
<br>Obviously, this strategy is only relevant for B&#39;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&#39;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" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1721430083533000&amp;usg=3DAOvVaw1=
y89lAmnq8-9pFsh6oQvRT">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1721430083533000&amp;usg=3DAOvVaw3j467IOtNKRr=
G3tYNuS6Kh">petertodd.org</a>
<br></blockquote></div>

<p></p>

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

------=_Part_227715_898393524.1721343887379--

------=_Part_227714_1014636734.1721343887379--