From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 19 Jul 2024 23:51:18 -0700 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sV3w4-0003K1-BY for bitcoindev@gnusha.org; Fri, 19 Jul 2024 23:51:17 -0700 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e05ec8921fdsf5666942276.1 for ; Fri, 19 Jul 2024 23:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721458270; x=1722063070; 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=GHeXiCoNlUk1MQPiD1hrAQQuJLbxdW2U08DxW6VGoHs=; b=Jb1y3hdiozUElGzm0JVyEDIH2J3DRwfWrBMC0NM2T1ILIIHYNFAor898u2/ETLHn8I M9qQd69AXdiKBo8NLWGC2y28eLHTFrf1aQM00MH6dt3Edgw7UDABjPIS7tZqYGs35txw 9vVGc7vg7R/Jwf7oU1ua4pR8WPaLtj+IlTk16W2We2Dv1lC31I+S0r+9knB4Ab7F253L w7OJWoebV2/N1z2Nau5QNe5SG3bnzyaxQyMj98L+Vto7YQhxTLV2vdNzUs1/vEiATmib 9KrEbXL3FuMgw1mkm1TgNfw91s5eGNQ4c1scLk9cMJRtWF/preFAqk/qfOPgWWU+TIIT WgZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721458270; x=1722063070; 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=GHeXiCoNlUk1MQPiD1hrAQQuJLbxdW2U08DxW6VGoHs=; b=Fl4q9mJdCKdEamsfxsZAu7Yiqj/NZmQb5JePuRbWBNWZPj9Oi6Y5l5n5I+1uBuWJBN lyllgn8VmE2iITnRWsDAGOgXNkTvm2Ij8A5+fNYyeU+DLRszmRPKwpbj6CruxCu1qU+A ozhYN5a+KG3raPQxEFSvXQqF1+w/qRamv3VRKS48lLINjIrzyHZafv99fnc+Av8UV8sR 6D61hvaHlTPB7275SrJgD0JrFHYaeuzATA2fUEWX2tyAHq3N3BRCnU+DHIWcpNj0E1C9 0C89zodmWSIVO9P95FSGPa55/C2svKEO+LaoM9isAjK5hLX9UCkoYXWI3NpHJ5b+vLNZ azvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721458270; x=1722063070; 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=GHeXiCoNlUk1MQPiD1hrAQQuJLbxdW2U08DxW6VGoHs=; b=Y112cTBVRE8gpyStaHikgRFfYsWoahi5nA+tcl11RawGaz3Ww7A58PJA+p9w63hc9Z e5S+kcLpNV+W3N9k6F1X7rqisQAu4WsJwyfQ5Faf7avhfQ90ptDvGrh8fH2bl+aToAku +SRRc2wBH7CqPQi8RQMWetVW9sYQXgeUBGeNs3YW/aumf8V6a2MocE0gwNZj0vQlXXiz c0aQC+fNWoA6BKqtwdpjy+GhjnmcLGnxNUg/s3mPlyuLgGzaQPkQRyDDIgLq57iTAH/X iHgtOiDx8pPVbcBPHQzWZz8N2ytsz4C5x+taFdz0kaGhhB2VWBrlen7sxXW4wyZXteVc oqTw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVgn+IHZpxKd9kBcWGMJnU0nGe1ZHmHeYqW78ylDjy2xaapnrbDJx7srltNa1WYXKL0R1//ePbJbAKgBOaPDqz7EZr4yc4= X-Gm-Message-State: AOJu0YwejEPzEGUAIeAFCtxcdiGwsvH0A+5FbHD/ASzclvHapQXe4/Ik +MvJrT4lQbJn67x18Lvd5F/NQmgh7A1Gs9lgNW/Q0z3d09TdH/3z X-Google-Smtp-Source: AGHT+IFwtZXeBcjBpH6bq/Szm0J7oXepBQTIQ3Y7AKu5o+Zr5HfBCd+2KRSeVm6dqQpgnlpiP51EEg== X-Received: by 2002:a05:6902:1241:b0:e08:782f:b68a with SMTP id 3f1490d57ef6-e08782fba45mr1214656276.17.1721458269723; Fri, 19 Jul 2024 23:51:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:53c2:0:b0:e03:aa7a:bb87 with SMTP id 3f1490d57ef6-e05fd8ce7fals4371132276.0.-pod-prod-09-us; Fri, 19 Jul 2024 23:51:08 -0700 (PDT) X-Received: by 2002:a05:690c:2a44:b0:650:a16c:91ac with SMTP id 00721157ae682-66a66d16f5dmr428687b3.8.1721458268313; Fri, 19 Jul 2024 23:51:08 -0700 (PDT) Received: by 2002:a05:690c:26c7:b0:627:7f59:2eee with SMTP id 00721157ae682-6691747e85ems7b3; Fri, 19 Jul 2024 22:57:41 -0700 (PDT) X-Received: by 2002:a05:6902:70c:b0:e05:a1df:5644 with SMTP id 3f1490d57ef6-e086f9963bemr61220276.2.1721455060940; Fri, 19 Jul 2024 22:57:40 -0700 (PDT) Date: Fri, 19 Jul 2024 22:57:40 -0700 (PDT) From: /dev /fd0 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com> References: <18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com> <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com> Subject: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_315086_645987492.1721455060728" X-Original-Sender: alicexbtong@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_315086_645987492.1721455060728 Content-Type: multipart/alternative; boundary="----=_Part_315087_1827213981.1721455060728" ------=_Part_315087_1827213981.1721455060728 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, > I'm interested if you can propose a formal or mathematical definition of= =20 what constitute > an in-topic of off-topic comments on a matters like full RBF, which has= =20 been controversial > for like a decade. I will quote _willcl-ark_'s last comment as I do not have enough=20 permissions in bitcoin core repository to moderate comments: "However the comments section here has become difficult to follow due to=20 numerous off-topic comments, a few personal disagreements, and repetition= =20 of arguments. In the interest of having a more productive and focused=20 technical and philosophical discussion we are going to close and lock this= =20 PR." A new pull request should help reviewers. If you do not agree with it, feel= =20 free to discuss it with moderators in bitcoin core IRC channel. > Again, I'm interested if you can propose a formal or mathematical=20 definition of what constitute > a reasonable bitcoin core vulnerability handling policy and that way give= =20 more ground on qualifying > if a present situation is falling out of this reasonable guidelines and= =20 that can be qualified more > objectively as "politics". Related discussion: https://github.com/bitcoin-core/meta/issues/5 > I think we have a mailing list to favorize textual long format and=20 encourage a more self-reflexive > mode of reasoning in the conduct of bitcoin engineering discussions. I=20 believe comments not bringing > new factual information or pointing to past experiences or concrete piece= =20 of information are better > left to twitter / nostr / reddit, whatever other communication channel=20 where the scientific and > ethics of conversation standards are less stringent. Ironically, this is exactly how moderation works in bitcoin core pull=20 requests and some comments were marked off-topic.. I have opened a pull request with the same commits (Peter Todd being the=20 author) to enable Full RBF by default:=20 https://github.com/bitcoin/bitcoin/pull/30493 /dev/fd0 floppy disk guy On Saturday, July 20, 2024 at 12:01:12=E2=80=AFAM UTC Antoine Riard wrote: > Hi /dev/fd0 > > > The last comment in the pull request suggests opening a new pull reques= t=20 > to enable full RBF by default, referencing the one closed due to off-topi= c=20 > comments. > > I'm interested if you can propose a formal or mathematical definition of= =20 > what constitute > an in-topic of off-topic comments on a matters like full RBF, which has= =20 > been controversial > for like a decade. I can only think such definition could make future=20 > conversations about > the boundaries of what is in / off bitcoin engineering topic more=20 > objective. > > > It seems that you are the one trying to politicize this issue. > > Let's be realistic on the state of bitcoin core security issues handling= =20 > in the recent words of > a group of some active contributors: > > "The project has historically done a poor job at publicly disclosing=20 > security-critical bugs, whether > externally reported or found by contributors. This has led to a situation= =20 > where a lot of users perceive > Bitcoin Core as never having bugs. This perception is dangerous and,=20 > unfortunately, not accurate." [0]. > > [0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w > > Again, I'm interested if you can propose a formal or mathematical=20 > definition of what constitute > a reasonable bitcoin core vulnerability handling policy and that way give= =20 > more ground on qualifying > if a present situation is falling out of this reasonable guidelines and= =20 > that can be qualified more=20 > objectively as "politics". > > I think we have a mailing list to favorize textual long format and=20 > encourage a more self-reflexive > mode of reasoning in the conduct of bitcoin engineering discussions. I=20 > believe comments not bringing > new factual information or pointing to past experiences or concrete piece= =20 > of information are better > left to twitter / nostr / reddit, whatever other communication channel=20 > where the scientific and > ethics of conversation standards are less stringent. > > All that said, I'm thinking to agree that the usage of all political=20 > rhethoric is a fallacy better > left for expressions on other communication channels and this is note wis= e=20 > to bundle it with novel > technical information, as from the outset it does not favor to concentrat= e=20 > the discussion on the fact > and logical reasoning themselves. Even more, political rhetoric very=20 > easily downgrade in moralistic > contest among protagonists on who has the monopole of the good / truth.= =20 > Somehow bitcoin is beyond > good and evil (-- under some long-term and abstract perspective). > > Best, > Antoine > ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fda= b > Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev /fd0 a =C3=A9crit= : > >> Hi Peter, >> >> > I didn't get a substantive >> > response from Bitcoin Core, other than Core closing the my pull-req=20 >> enabling >> > full-RBF by default that would fix this specific vulnerability. >> >> The last comment in the pull request suggests opening a new pull request= =20 >> to enable full RBF by default, referencing the one closed due to off-top= ic=20 >> comments.=20 >> >> > But read on, this is quite an odd case of Core politics, and the story= =20 >> is not >> > as simple as Core refusing to fix a vulnerability. >> >> It seems that you are the one trying to politicize this issue.=20 >> >> /dev/fd0 >> floppy disk guy >> >> On Thursday, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote: >> >>> # Summary=20 >>> >>> This is a public disclosure of a vulnerability that I previously=20 >>> disclosed to=20 >>> the bitcoin-security mailing list. It's an easy vulnerability to fix.= =20 >>> Although=20 >>> as with other "free" relay attacks I've disclosed, I didn't get a=20 >>> substantive=20 >>> response from Bitcoin Core, other than Core closing the my pull-req=20 >>> enabling=20 >>> full-RBF by default that would fix this specific vulnerability.=20 >>> >>> But read on, this is quite an odd case of Core politics, and the story= =20 >>> is not=20 >>> as simple as Core refusing to fix a vulnerability. Also, I've including= =20 >>> a fun=20 >>> homework problem at the end: figure out how TRUC/V3 transactions itself= =20 >>> creates=20 >>> a "free" relay attack.=20 >>> >>> >>> # Background=20 >>> >>> This is just one of a few "free" relay attacks that I have recently=20 >>> disclosed,=20 >>> including, but not limited to:=20 >>> >>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024=20 >>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg=20 >>> >>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st= =20 >>> 2024=20 >>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo=20 >>> >>> The term "free relay attack" simply refers to any mechanism where=20 >>> transaction=20 >>> data can be broadcast at unusually low cost; the "free" in "free relay"= =20 >>> is a=20 >>> misnomer as all these attacks do in fact have some cost.=20 >>> >>> This particular attack isn't significantly different than the other=20 >>> attacks=20 >>> I've disclosed. With one important exception: unlike those other=20 >>> attacks,=20 >>> fixing this particular attack would be quite easy, by enabling full-rbf= =20 >>> by=20 >>> default. So I disclosed it to the bitcoin-security mailing list as a=20 >>> test: does=20 >>> Bitcoin Core actually care about free relay attacks? My hypothesis is= =20 >>> that Core=20 >>> does not, as they know full well that "free" relay is an unavoidable=20 >>> problem;=20 >>> I've received absolutely no feedback from any Bitcoin Core members for= =20 >>> the=20 >>> other disclosed attacks, beyond achow using my disclosure of the RBF=20 >>> Rule #6=20 >>> attack as an excuse to remove me from the bitcoin-security mailing list= .=20 >>> >>> The fact that Core doesn't actually care about "free" relay attacks is= =20 >>> relevant=20 >>> to TRUC/V3 Transactions. As per BIP-431:=20 >>> >>> "The primary problem with [RBFR proposals] is the potential for free=20 >>> relay and DDoS attacks.=20 >>> >>> Removing Rule 3 and 4 in general would allow free relay [27]."=20 >>> >>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a= 428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate=20 >>> >>> I believe the authors of that BIP are fully aware of the fact that=20 >>> "free" relay=20 >>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and= =20 >>> don't=20 >>> want to admit that they've wasted a large amount of engineering time on= =20 >>> a bad=20 >>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as= =20 >>> the many=20 >>> "free" relay attacks I've disclosed clearly show that claiming RBFR=20 >>> would=20 >>> "allow" free relay is simply not true.=20 >>> >>> Notably, full-RBF is _itself_ a transaction pinning fix for many=20 >>> use-cases;=20 >>> part of the TRUC/V3 standard is to force full-RBF behavior for V3=20 >>> transactions.=20 >>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a=20 >>> second=20 >>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF= =20 >>> option=20 >>> removed from Core in the first place. If not for this dumb bit of Core= =20 >>> politics, I'm sure my year-old pull-req to enable full-RBF by default= =20 >>> would=20 >>> have been merged many months ago, as almost all hashpower has adopted= =20 >>> full-RBF=20 >>> making objections based on "zeroconf" absurd.=20 >>> >>> >>> # The Attack=20 >>> >>> If you're a competent Bitcoin engineer, familiar with how mempools work= ,=20 >>> you've=20 >>> probably figured it out already based on the title: obviously, if a hig= h=20 >>> percentage of miners are adopting a policy that Bitcoin Core nodes are= =20 >>> not, you=20 >>> can cheaply consume transaction relay bandwidth by simply relaying=20 >>> transations=20 >>> that miners are rejecting.=20 >>> >>> Specifically, do the following:=20 >>> >>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.= =20 >>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.= =20 >>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with= =20 >>> BIP-125=20 >>> opt-in enabled. ~100% of miners will reject B, as it spends an input no= t=20 >>> in=20 >>> their mempools. However Bitcoin Core nodes will waste bandwidth=20 >>> propagating=20 >>> B.=20 >>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will= =20 >>> waste=20 >>> bandwidth propagating Bn's that ~100% of miners are ignoring.=20 >>> 5. Double-spend A2 to recover your funds and do it all over again (or i= f=20 >>> A2 had=20 >>> a high enough fee-rate, just wait for it to be mined).=20 >>> >>> The cost to relay each B transaction depends on the fee-rate of B. Sinc= e=20 >>> Bitcoin Core defaults to a fairly large mempool, the minimum relay=20 >>> fee-rate is=20 >>> typically well below the economic fee-rate required for miners to=20 >>> actually mine=20 >>> a transaction; Core accepts transactions that are uneconomical for=20 >>> miners to=20 >>> mine for the forseeable future.=20 >>> >>> For example, at the moment typical mempools require transactions to pay= =20 >>> at=20 >>> least 1sat/vB, while there are hundreds of MvB worth of transactions=20 >>> paying=20 >>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying les= s=20 >>> than=20 >>> 4sat/VB are extremely unlikely to get mined in the nearish future.=20 >>> >>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v= B=20 >>> would=20 >>> have almost zero cost as the probability of those transactions getting= =20 >>> mined is=20 >>> nearly zero. This is true _regardless_ of what % of miners are mining= =20 >>> full-RBF!=20 >>> As long as you can get at least one miner to mine the A double-spend,= =20 >>> the=20 >>> attack only costs what it cost to get A mined.=20 >>> >>> If B's are broadcast at a higher fee-rate than the minimum economical= =20 >>> fee-rate,=20 >>> then the % of full-RBF miners matters. For example, if only 99% of=20 >>> miners mine=20 >>> full-RBF, the chance of a B transaction getting mined per block is abou= t=20 >>> 1%, so=20 >>> the amortized cost of broadcasting B is about 1% of whatever total fee= =20 >>> the=20 >>> highest fee-rate variant of B pays.=20 >>> >>> For an attacker who does not need any B to be broadcast, the cost=20 >>> savings to=20 >>> use of relay bandwidth is approximately the ratio of the difference in= =20 >>> size=20 >>> between B and and A. With a maximum standard transaction size of 100KvB= ,=20 >>> or=20 >>> 400KB serialized size, this ratio is on the order of 5000:1, times the= =20 >>> total=20 >>> number of B variants broadcast, and the % chance of each B being mined;= =20 >>> it's a=20 >>> few orders of magnitude.=20 >>> >>> Of course, as mentioned above, this is just one of *many* "free" relay= =20 >>> attacks,=20 >>> so fixing this particular issue doesn't change much.=20 >>> >>> >>> # Attackers Who Benefit From B Getting Mined=20 >>> >>> Some attackers actually need B to get mined. For example, imagine an=20 >>> exchange=20 >>> who needs to do large consolidation transactions. They could use this= =20 >>> attack=20 >>> (and some attacks like it) as a way to goad users and miners into minin= g=20 >>> consolidation transactions for them at low cost. In this variant of the= =20 >>> attack,=20 >>> the attacker would pad the size of B with consolidation spends that the= y=20 >>> needed=20 >>> to do anyway. Someone who tried to stop the attack by getting B mined= =20 >>> (eg via=20 >>> mempool.space's transaction accellerator) would simply be paying the=20 >>> attacker's=20 >>> fees for them.=20 >>> >>> Obviously, this strategy is only relevant for B's below the economic=20 >>> fee-rate.=20 >>> However, the weaker version of this strategy is to parallize the attack= ,=20 >>> and do=20 >>> your consolidation with the _A_ double-spends to reduce the # of bytes= =20 >>> used per=20 >>> full-rbf double-spend.=20 >>> >>> >>> # TRUC/V3 Creates a Free Relay Attack=20 >>> >>> I'll leave the details of this as a homework problem. But obviously, th= e=20 >>> introduction of TRUC/V3 transactions *itself* creates a free relay=20 >>> attack very=20 >>> similar to the above! Just like full-RBF, not all miners will mine V3= =20 >>> transactions. So you can do the exact same type of attack by taking=20 >>> advantage=20 >>> of this difference in mining policy.=20 >>> >>> --=20 >>> https://petertodd.org 'peter'[:-1]@petertodd.org=20 >>> >> --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com. ------=_Part_315087_1827213981.1721455060728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine,

>=C2=A0 I'm interested if you can propose a formal or mathematical definition of wh= at constitute
> an in-topic of off-topic comments on a matters like= full RBF, which has been controversial
> for like a decade.
<= br />I will quote _willcl-ark_'s last comment as I do not have enough permi= ssions in bitcoin core repository to moderate comments:

"However the comments section here has become difficult to follow d= ue to numerous off-topic comments, a few personal disagreements, and repeti= tion of arguments. In the interest of having a more productive and focused = technical and philosophical discussion we are going to close and lock this = PR."

A new pull request should help reviewers. I= f you do not agree with it, feel free to discuss it with moderators in bitc= oin core IRC channel.

>=C2=A0 Again, I'm interested if you can propose a formal or mathematical definitio= n of what constitute
> a reasonable bitcoin core vulnerability hand= ling policy and that way give more ground on qualifying
> if a pres= ent situation is falling out of this reasonable guidelines and that can be = qualified more
> objectively as "politics".

Related disc= ussion:=C2=A0http= s://github.com/bitcoin-core/meta/issues/5

&g= t;=C2=A0I think we have a mailing list to favorize textual long format and = encourage a more self-reflexive
> mode of reasoning in the conduct = of bitcoin engineering discussions. I believe comments not bringing
&g= t; new factual information or pointing to past experiences or concrete piec= e of information are better
> left to twitter / nostr / reddit, wha= tever other communication channel where the scientific and
> ethics= of conversation standards are less stringent.

I= ronically, this is exactly how moderation works in bitcoin core pull reques= ts and some comments were marked off-topic..

I h= ave opened a pull request with the same commits (Peter Todd being the autho= r) to enable Full RBF by default:=C2=A0https://github.com/bitcoin/bitcoin/pull/30493

/dev/fd0
floppy disk guy

On Satur= day, July 20, 2024 at 12:01:12=E2=80=AFAM UTC Antoine Riard wrote:
Hi /dev/fd0

&g= t; 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= comments.

I'm interested if you can propose a formal or mathema= tical definition of what constitute
an in-topic of off-topic comments on= a matters like full RBF, which has been controversial
for like a decade= . I can only think such definition could make future conversations aboutthe boundaries of what is in / off bitcoin engineering topic more objectiv= e.

> It seems that you are the one trying to politicize this issu= e.

Let's be realistic on the state of bitcoin core security issu= es handling in the recent words of
a group of some active contributors:<= br>
"The project has historically done a poor job at publicly discl= osing security-critical bugs, whether
externally reported or found by co= ntributors. This has led to a situation where a lot of users perceive
Bi= tcoin Core as never having bugs. This perception is dangerous and, unfortun= ately, not accurate." [0].

[0] https://groups.google.com/= g/bitcoindev/c/Q2ZGit2wF7w

Again, I'm interested if you can = propose a formal or mathematical definition of what constitute
a reasona= ble bitcoin core vulnerability handling policy and that way give more groun= d on qualifying
if a present situation is falling out of this reasonable= guidelines and that can be qualified more
objectively as "politic= s".

I think we have a mailing list to favorize textual long for= mat and encourage a more self-reflexive
mode of reasoning in the conduct= of bitcoin engineering discussions. I believe comments not bringing
new= factual information or pointing to past experiences or concrete piece of i= nformation are better
left to twitter / nostr / reddit, whatever other c= ommunication channel where the scientific and
ethics of conversation sta= ndards are less stringent.

All that said, I'm thinking to agree = that the usage of all political rhethoric is a fallacy better
left for e= xpressions on other communication channels and this is note wise to bundle = it with novel
technical information, as from the outset it does not favo= r to concentrate the discussion on the fact
and logical reasoning themse= lves. Even more, political rhetoric very easily downgrade in moralistic
= contest among protagonists on who has the monopole of the good / truth. Som= ehow bitcoin is beyond
good and evil (-- under some long-term and abstra= ct perspective).

Best,
Antoine
ots hash: 3088507ecfb55ed301bb0= defce9fb490daa6bb9594e96d57336d603556a8fdab
<= div dir=3D"auto" class=3D"gmail_attr">Le vendredi 19 juillet 2024 =C3=A0 19= :27:36 UTC+1, /dev /fd0 a =C3=A9crit=C2=A0:
Hi Peter,

>=C2=A0I didn't get a substan= tive
> response from Bitcoin Core, other than Core closing the my pul= l-req enabling
> full-RBF by default that would fix this specific vul= nerability.

The last comment in the pull request suggests opening a new pull request to= enable full RBF by default, referencing the one closed due to off-topic co= mments.

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

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

/dev/fd0
floppy disk guy

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

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

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


# Background

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

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

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

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

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

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

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

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

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

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


# The Attack

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

Specifically, do the following:

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

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

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

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

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

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

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


# Attackers Who Benefit From B Getting Mined

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

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


# TRUC/V3 Creates a Free Relay Attack

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

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

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com.=
------=_Part_315087_1827213981.1721455060728-- ------=_Part_315086_645987492.1721455060728--