diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2024-07-18 16:04:47 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-07-18 16:10:37 -0700 |
| commit | a1ce54e58f90a561a701fa9f73b05c3b1c33ebe1 (patch) | |
| tree | 17fd968644381e097f06d5230501762a98414a19 | |
| parent | 4da248663a1ce8c2f5b35077799734bf435d1ea5 (diff) | |
| download | pi-bitcoindev-a1ce54e58f90a561a701fa9f73b05c3b1c33ebe1.tar.gz pi-bitcoindev-a1ce54e58f90a561a701fa9f73b05c3b1c33ebe1.zip | |
[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
| -rw-r--r-- | 0d/0314d14dbd9f9698f1dc399bd20c48ad1e75f1 | 816 |
1 files changed, 816 insertions, 0 deletions
diff --git a/0d/0314d14dbd9f9698f1dc399bd20c48ad1e75f1 b/0d/0314d14dbd9f9698f1dc399bd20c48ad1e75f1 new file mode 100644 index 000000000..f081cee37 --- /dev/null +++ b/0d/0314d14dbd9f9698f1dc399bd20c48ad1e75f1 @@ -0,0 +1,816 @@ +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's an easy vulnerability to fi= +x. Although +<br>as with other "free" relay attacks I've disclosed, I didn= +'t get a substantive +<br>response from Bitcoin Core, other than Core closing the my pull-req ena= +bling +<br>full-RBF by default that would fix this specific vulnerability. +<br> +<br>But read on, this is quite an odd case of Core politics, and the story = +is not +<br>as simple as Core refusing to fix a vulnerability. Also, I've inclu= +ding a fun +<br>homework problem at the end: figure out how TRUC/V3 transactions itself= + creates +<br>a "free" relay attack. +<br> +<br> +<br># Background +<br> +<br>This is just one of a few "free" relay attacks that I have re= +cently disclosed, +<br>including, but not limited to: +<br> +<br> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2= +024 +<br> <a href=3D"https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg" ta= +rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google= +.com/url?hl=3Dfr&q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV= +hg&source=3Dgmail&ust=3D1721430083533000&usg=3DAOvVaw28pIvfydLe= +rmZuJr4Xteiu">https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg</a> +<br> +<br> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences"= +; - Mar 31st 2024 +<br> <a href=3D"https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo" ta= +rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google= +.com/url?hl=3Dfr&q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX= +qo&source=3Dgmail&ust=3D1721430083533000&usg=3DAOvVaw2ciEmH2LtR= +H29UHsN69zTJ">https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo</a> +<br> +<br>The term "free relay attack" simply refers to any mechanism w= +here transaction +<br>data can be broadcast at unusually low cost; the "free" in &q= +uot;free relay" is a +<br>misnomer as all these attacks do in fact have some cost. +<br> +<br>This particular attack isn't significantly different than the other= + attacks +<br>I've disclosed. With one important exception: unlike those other at= +tacks, +<br>fixing this particular attack would be quite easy, by enabling full-rbf= + by +<br>default. So I disclosed it to the bitcoin-security mailing list as a te= +st: does +<br>Bitcoin Core actually care about free relay attacks? My hypothesis is t= +hat Core +<br>does not, as they know full well that "free" relay is an unav= +oidable problem; +<br>I've received absolutely no feedback from any Bitcoin Core members = +for the +<br>other disclosed attacks, beyond achow using my disclosure of the RBF Ru= +le #6 +<br>attack as an excuse to remove me from the bitcoin-security mailing list= +. +<br> +<br>The fact that Core doesn't actually care about "free" rel= +ay attacks is relevant +<br>to TRUC/V3 Transactions. As per BIP-431: +<br> +<br> "The primary problem with [RBFR proposals] is the potential fo= +r free relay and DDoS attacks. +<br> +<br> Removing Rule 3 and 4 in general would allow free relay [27]." +<br> <a href=3D"https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e= +2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_= +by_feerate" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"http= +s://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/bitcoin/bips/blob= +/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content= +-Alternatives_replace_by_feerate&source=3Dgmail&ust=3D1721430083533= +000&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" relay +<br>is an unavoidable problem, making their rational for TRUC/V3 bogus, and= + don't +<br>want to admit that they've wasted a large amount of engineering tim= +e on a bad +<br>proposal. I will be submitting a pull-req to get BIP-431 corrected, as = +the many +<br>"free" relay attacks I've disclosed clearly show that cla= +iming RBFR would +<br>"allow" free relay is simply not true. +<br> +<br>Notably, full-RBF is _itself_ a transaction pinning fix for many use-ca= +ses; +<br>part of the TRUC/V3 standard is to force full-RBF behavior for V3 trans= +actions. +<br>So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a se= +cond +<br>way, and TRUC/V3 proponents were the ones who tried to get the full-RBF= + option +<br>removed from Core in the first place. If not for this dumb bit of Core +<br>politics, I'm sure my year-old pull-req to enable full-RBF by defau= +lt would +<br>have been merged many months ago, as almost all hashpower has adopted f= +ull-RBF +<br>making objections based on "zeroconf" absurd. +<br> +<br> +<br># The Attack +<br> +<br>If you're a competent Bitcoin engineer, familiar with how mempools = +work, you've +<br>probably figured it out already based on the title: obviously, if a hig= +h +<br>percentage of miners are adopting a policy that Bitcoin Core nodes are = +not, you +<br>can cheaply consume transaction relay bandwidth by simply relaying tran= +sations +<br>that miners are rejecting. +<br> +<br>Specifically, do the following: +<br> +<br>1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled. +<br>2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate. +<br>3. Spend the outputs of A in a large, low fee-rate, transaction B with = +BIP-125 +<br> opt-in enabled. ~100% of miners will reject B, as it spends an input= + not in +<br> their mempools. However Bitcoin Core nodes will waste bandwidth prop= +agating +<br> B. +<br>4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will= + waste +<br> bandwidth propagating Bn's that ~100% of miners are ignoring. +<br>5. Double-spend A2 to recover your funds and do it all over again (or i= +f A2 had +<br> a high enough fee-rate, just wait for it to be mined). +<br> +<br>The cost to relay each B transaction depends on the fee-rate of B. Sinc= +e +<br>Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-= +rate is +<br>typically well below the economic fee-rate required for miners to actua= +lly mine +<br>a transaction; Core accepts transactions that are uneconomical for mine= +rs to +<br>mine for the forseeable future. +<br> +<br>For example, at the moment typical mempools require transactions to pay= + at +<br>least 1sat/vB, while there are hundreds of MvB worth of transactions pa= +ying +<br>4sat/vB, the minimum economical fee-rate. Thus, transactions paying les= +s than +<br>4sat/VB are extremely unlikely to get mined in the nearish future. +<br> +<br>Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v= +B would +<br>have almost zero cost as the probability of those transactions getting = +mined is +<br>nearly zero. This is true _regardless_ of what % of miners are mining f= +ull-RBF! +<br>As long as you can get at least one miner to mine the A double-spend, t= +he +<br>attack only costs what it cost to get A mined. +<br> +<br>If B's are broadcast at a higher fee-rate than the minimum economic= +al fee-rate, +<br>then the % of full-RBF miners matters. For example, if only 99% of mine= +rs mine +<br>full-RBF, the chance of a B transaction getting mined per block is abou= +t 1%, so +<br>the amortized cost of broadcasting B is about 1% of whatever total fee = +the +<br>highest fee-rate variant of B pays. +<br> +<br>For an attacker who does not need any B to be broadcast, the cost savin= +gs to +<br>use of relay bandwidth is approximately the ratio of the difference in = +size +<br>between B and and A. With a maximum standard transaction size of 100KvB= +, or +<br>400KB serialized size, this ratio is on the order of 5000:1, times the = +total +<br>number of B variants broadcast, and the % chance of each B being mined;= + it's a +<br>few orders of magnitude. +<br> +<br>Of course, as mentioned above, this is just one of *many* "free&qu= +ot; relay attacks, +<br>so fixing this particular issue doesn't change much. +<br> +<br> +<br># Attackers Who Benefit From B Getting Mined +<br> +<br>Some attackers actually need B to get mined. For example, imagine an ex= +change +<br>who needs to do large consolidation transactions. They could use this a= +ttack +<br>(and some attacks like it) as a way to goad users and miners into minin= +g +<br>consolidation transactions for them at low cost. In this variant of the= + attack, +<br>the attacker would pad the size of B with consolidation spends that the= +y needed +<br>to do anyway. Someone who tried to stop the attack by getting B mined (= +eg via +<br><a href=3D"http://mempool.space" target=3D"_blank" rel=3D"nofollow" dat= +a-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttp://memp= +ool.space&source=3Dgmail&ust=3D1721430083533000&usg=3DAOvVaw3I3= +8uX9YFHZK8Dg2u_C1dQ">mempool.space</a>'s transaction accellerator) woul= +d simply be paying the attacker's +<br>fees for them. +<br> +<br>Obviously, this strategy is only relevant for B's below the economi= +c fee-rate. +<br>However, the weaker version of this strategy is to parallize the attack= +, and do +<br>your consolidation with the _A_ double-spends to reduce the # of bytes = +used per +<br>full-rbf double-spend. +<br> +<br> +<br># TRUC/V3 Creates a Free Relay Attack +<br> +<br>I'll leave the details of this as a homework problem. But obviously= +, the +<br>introduction of TRUC/V3 transactions *itself* creates a free relay atta= +ck very +<br>similar to the above! Just like full-RBF, not all miners will mine V3 +<br>transactions. So you can do the exact same type of attack by taking adv= +antage +<br>of this difference in mining policy. +<br> +<br>--=20 +<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da= +ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://pe= +tertodd.org&source=3Dgmail&ust=3D1721430083533000&usg=3DAOvVaw1= +y89lAmnq8-9pFsh6oQvRT">https://petertodd.org</a> 'peter'[:-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&q=3Dhttp://petertodd.org= +&source=3Dgmail&ust=3D1721430083533000&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" 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-- + |