diff options
| author | /dev /fd0 <alicexbtong@gmail.com> | 2024-07-19 05:41:06 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-07-19 11:27:44 -0700 |
| commit | ebc95c9932163727048058a9bfc7592308b06eb1 (patch) | |
| tree | ada7173cfae30c64e9502fe4802009b15f139bc2 | |
| parent | 3f943835f35390fca572e5bedc9a714fd60e8b86 (diff) | |
| download | pi-bitcoindev-ebc95c9932163727048058a9bfc7592308b06eb1.tar.gz pi-bitcoindev-ebc95c9932163727048058a9bfc7592308b06eb1.zip | |
[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
| -rw-r--r-- | 9d/5b40e97e215450d8e5284b9ea9af1317e66973 | 669 |
1 files changed, 669 insertions, 0 deletions
diff --git a/9d/5b40e97e215450d8e5284b9ea9af1317e66973 b/9d/5b40e97e215450d8e5284b9ea9af1317e66973 new file mode 100644 index 000000000..9b20ab9a8 --- /dev/null +++ b/9d/5b40e97e215450d8e5284b9ea9af1317e66973 @@ -0,0 +1,669 @@ +Delivery-date: Fri, 19 Jul 2024 11:27:44 -0700 +Received: from mail-yb1-f189.google.com ([209.85.219.189]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCU2P6FJ3EBBBF7A5K2AMGQEYCHJEAA@googlegroups.com>) + id 1sUsKV-0007hy-2O + for bitcoindev@gnusha.org; Fri, 19 Jul 2024 11:27:44 -0700 +Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e05e9e4dfbesf4923694276.1 + for <bitcoindev@gnusha.org>; Fri, 19 Jul 2024 11:27:42 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1721413657; x=1722018457; 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=At36Vbhot8pETgQCkBAipoL+dSaeFcHRDCDEWJnAJ9A=; + b=BQZjyNfrCQMnbzNfvaa+iwa6SLp7m8EeIyffmK5ONEmTHSzxcgFrK4l84JytZ8gsGe + STFYsZEWfpBzyATvYo9PDPNWqv9onKhzvgtK3YYXyKRJnBWRUDOiafEJTdhsa5i8Nzpq + 88YcEYwoGiw0kNMdG+vuFEyFvzB4GZPenHVi7ne1kp3ocsTNS6FfTBsZhfBRiWJxFHTO + BQ11709oeesyk+rGGQoayq/q7wcxuaRtsmYc0/PokXy0uPCnBJUniuM6QwTHUOAJXzA3 + g52mgfVg7NPtXzeCViTJQ1/kNbbMrZOqlSRb1BuXvAn5J3jl3nTCEtb9L7cUtsaFtprN + /Qfw== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1721413657; x=1722018457; 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=At36Vbhot8pETgQCkBAipoL+dSaeFcHRDCDEWJnAJ9A=; + b=jDmGsN6l/w6XwbnSoy4c1KJVGTw3Y7ezf/bXM92Ex90KQRwXd60XF40u6MCdIaHk1e + Ij3Tw5J41SSAOlv0RCBNr3D4r++9pzEKSvJNzTdVIdkDcvfYVjHEIDD/mlnArYfyY/RL + Jpueo/3173yQqgAyE2rJ7OpFrj3KJbQqUhQcVIMSzT03NYAvmkez4MOSqnutgWtGR4Yv + Wiv9OTP314XNHIhUcFEM80fySe4jfxgjIBi3tMHR4vmmzb46MZEtKldZgtGfv6pd+Hkk + 2zrILESYgyI9bYNXHS8wbQGNtY4cK3z1SmaEWkgn4gXHbbB9YGgy1AcsL/prk1i1csD/ + 7n/w== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1721413657; x=1722018457; + 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=At36Vbhot8pETgQCkBAipoL+dSaeFcHRDCDEWJnAJ9A=; + b=UkBQl/5Xs/tONbRxqSoLAidEco6D33zkzL6I0A6bnTPm3mS5fwGqkecxfAyE8g3vW7 + WGh6sZCvYK236xw8YFRv2CtJgPSgX1CHqB/hRbyJ69GZ6BeFORg4Hgl2Upg1HwPL6i7m + ivzbcbsfEwfoM30150ir28vj9KTD+x/GDxq19Li7X9P/h0XQLQ72+LLl2KgVDUZATS8S + BFOcMqW2CJPp0MmkdaOdO6SHaKgt3Vy0XM77/WobT5WD0I9uhCuQE3Lbvq4fz5nPOpvT + XrXOCmTFXuqb5b2WyeZ71+pVWAGOlOmNfYI+4YXjt5o/NWRe+iWnMfTjiyWwRgTTK60P + oTlA== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCVbYBIV3EVPGc19HU5eg0h+dp7eQzJ9YrImDWDV/tBicIMq/elhhRCaGsXhjERx9ab2h0iRtudcNY1Fe+Q6OhIEMLpcC1A= +X-Gm-Message-State: AOJu0YzC2Kinhv6IkhkFZiI1QcsVnQUMmYS4RV6hORQX9plvZEWizkPQ + nwPj8bvOJmL1FHnKYhynE4AOU3YAPGVSOWn3E2i2waJDeR3SorXp +X-Google-Smtp-Source: AGHT+IHUrjrLg53yrhRyLxl3zASDofVe/17D0bkefTBeHsutohY7zoOEClAwtHWmJzC7CmvyQEFKpA== +X-Received: by 2002:a05:6902:f81:b0:e08:6af2:d5b9 with SMTP id 3f1490d57ef6-e08706adb8amr534628276.49.1721413656710; + Fri, 19 Jul 2024 11:27:36 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a25:f912:0:b0:e03:6457:383f with SMTP id 3f1490d57ef6-e05fdb408a3ls3363212276.1.-pod-prod-09-us; + Fri, 19 Jul 2024 11:27:35 -0700 (PDT) +X-Received: by 2002:a25:8b86:0:b0:e03:2f90:e81d with SMTP id 3f1490d57ef6-e0870462b60mr8513276.11.1721413655165; + Fri, 19 Jul 2024 11:27:35 -0700 (PDT) +Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18bms7b3; + Fri, 19 Jul 2024 05:41:07 -0700 (PDT) +X-Received: by 2002:a05:6902:1004:b0:e03:2257:98b8 with SMTP id 3f1490d57ef6-e05feb3117bmr100638276.1.1721392866989; + Fri, 19 Jul 2024 05:41:06 -0700 (PDT) +Date: Fri, 19 Jul 2024 05:41:06 -0700 (PDT) +From: /dev /fd0 <alicexbtong@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <18a5e5a2-92b3-4345-853d-5a63b71d848bn@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_159328_1732340751.1721392866788" +X-Original-Sender: alicexbtong@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_159328_1732340751.1721392866788 +Content-Type: multipart/alternative; + boundary="----=_Part_159329_1526928484.1721392866788" + +------=_Part_159329_1526928484.1721392866788 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Peter, + +> I didn't get a substantive +> response from Bitcoin Core, other than Core closing the my pull-req=20 +enabling +> full-RBF by default that would fix this specific vulnerability. + +The last comment in the pull request suggests opening a new pull request to= +=20 +enable full RBF by default, referencing the one closed due to off-topic=20 +comments.=20 + +> 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. + +It seems that you are the one trying to politicize this issue.=20 + +/dev/fd0 +floppy disk guy + +On Thursday, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote: + +> # Summary +> +> 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/18a5e5a2-92b3-4345-853d-5a63b71d848bn%40googlegroups.com. + +------=_Part_159329_1526928484.1721392866788 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Peter,<br /><br />>=C2=A0I didn't get a substantive<br />> respons= +e from Bitcoin Core, other than Core closing the my pull-req enabling<br />= +> full-RBF by default that would fix this specific vulnerability.<br /><= +br /> + +The last comment in the pull request suggests opening a new pull request to= + enable full RBF by default, referencing the one closed due to off-topic co= +mments. + +<div><br /></div><div>>=C2=A0But read on, this is quite an odd case of C= +ore politics, and the story is not<br />> as simple as Core refusing to = +fix a vulnerability.</div><div><br /></div><div> + +It seems that you are the one trying to politicize this issue. + +</div><div><br /></div><div>/dev/fd0</div><div>floppy disk guy<br /><br /><= +/div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On T= +hursday, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:<br/></di= +v><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-le= +ft: 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=3Den&q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV= +hg&source=3Dgmail&ust=3D1721478911283000&usg=3DAOvVaw2tGCUebRo6= +vjKF8SKftMMH">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=3Den&q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX= +qo&source=3Dgmail&ust=3D1721478911284000&usg=3DAOvVaw3TOPkBQ_Nd= +JKtzd8KxxdVy">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=3Den&q=3Dhttps://github.com/bitcoin/bips/blob= +/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content= +-Alternatives_replace_by_feerate&source=3Dgmail&ust=3D1721478911284= +000&usg=3DAOvVaw3fh7gqD6KbjyJF9u5jDGnE">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=3Den&q=3Dhttp://memp= +ool.space&source=3Dgmail&ust=3D1721478911284000&usg=3DAOvVaw3LA= +8yoWHtUO8-O7KhNWIld">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=3Den&q=3Dhttps://pe= +tertodd.org&source=3Dgmail&ust=3D1721478911284000&usg=3DAOvVaw3= +Oozvov6XJ1qRfXOK6i_I7">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=3Den&q=3Dhttp://petertodd.org= +&source=3Dgmail&ust=3D1721478911284000&usg=3DAOvVaw17SWdmJvOinr= +lFD8MBev1B">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/18a5e5a2-92b3-4345-853d-5a63b71d848bn%40googlegroups.= +com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= +id/bitcoindev/18a5e5a2-92b3-4345-853d-5a63b71d848bn%40googlegroups.com</a>.= +<br /> + +------=_Part_159329_1526928484.1721392866788-- + +------=_Part_159328_1732340751.1721392866788-- + |