From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 21 Jul 2024 11:04:48 -0700 Received: from mail-yb1-f191.google.com ([209.85.219.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVavO-00029N-Ds for bitcoindev@gnusha.org; Sun, 21 Jul 2024 11:04:48 -0700 Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e035f7b5976sf11560482276.0 for ; Sun, 21 Jul 2024 11:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721585080; x=1722189880; 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=i907isOI7Ic48Xdj/a0b9YKRImQpBPS2y9NgEm01yKI=; b=YZSgHMmtRNTodN/vSCUp7mR9l/XIOugwtC6g01VYxiRMfGXa/+oKHD6cQ6kkcSE7sR NgXgvQoV7L8KBY54xYglmK62hHCKPJDfJZWhxC+o4xONdWTUpBd7ipgWHE3+DW2UEF0n KkUuOAl/DVPoCAkpZQXmmYl5bruQKnxf/G3xvcv3ptPqtCnVUygdS1S5IhIG261tR1Hq HhYtuc31w64v2GVzdZ+R5sXBI80CTQrGCsMZhRuLLB8Vlolw3ULHQB3A6KoULy/P8EmR fj/AplD0at6xnhDPabYK9xkn45WZN6tVN7QX6ZjVWjy8aPLzFEvBBXAFFRGBDQ3xN8lV H8Qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721585080; x=1722189880; 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=i907isOI7Ic48Xdj/a0b9YKRImQpBPS2y9NgEm01yKI=; b=YZRnKJJghIgo8rm7kiwkn8wg7AdowcvpjQpjq3nrYV3VoNh34mbXDHMD0TI3P58vPn xBH4dtRL5XU6zDDXP3C4Apj+X3pDzjhH9oPEgHQh4OZMhoL0rnUs75+bpFml1U7/A7tz gO1TyKcgedLkKlgUqmMVj4I3QBEOi/nRH+UF27NUX49riqxTMkG4b2lIF2SRAAWQHgxJ 34WwqC4zfhR9+hUfNre4klSmIdLZCX9oELz7RKr8vhJ/9IsC1Yue3fM9U0hUfcm3sWJT Y+rNZiqAkV6uF9QV9qTVTJGrTlXNiCUBpS8GJq9+J+NLwJs37L3GudKQsiAWE82ptUkL v71w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721585080; x=1722189880; 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=i907isOI7Ic48Xdj/a0b9YKRImQpBPS2y9NgEm01yKI=; b=teUACZzBtNRaiPpL2kIXxRoSFFmLSXTaorf85zbBhpBaa2rz/BjQub+QJS83FGUWX4 1a0LvThlDbr1iYb3J90UNbSF+lpHxQy7wVEBbPjIUf95ZubMOsNpjdMDCP8MfQ6qVraq uGe5yuAVOaGsPhXVodTUeAt9kxlwJH1CH/SnuygfpeIfs6N9Semor2lXouY0xjWi3+aM qkqYlHyhjoQqmtgMn2oMQZGfp/Elq5A0lOdqqMGmjzROADE3/6faNtCuiJGCA/kF7TGN 966v1HWur9xZ64QBJi3jcAn5CdTRnFVsdv2nYgWbLYvZdUuGCJxuguuFJLo0Jz1hZC82 sCeA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWQEccpFuAjqvHz4fndbzOIkZdg31HgR6JZUJBqZNzTPh5Ak92K49KTOkIsG7tMwWb9egnJPfV93bdc2ftGEgF3Z1fNouQ= X-Gm-Message-State: AOJu0YwT344IVUIMExY8cKWr6Cjq74OjLEe/U010IbyN9tDlrUBMUGMe Z+UXvotz2Ez7fwWi5HMHjDOj3n+1eYjS3cU0UAvrqEFOR12zTfnQ X-Google-Smtp-Source: AGHT+IFGtvyeWwrezxDZqKa0yjkhEejB4yu8i1n2sRTjmS+txokvSE/G53ysQOmthaqX77z011z8ag== X-Received: by 2002:a05:6902:2b06:b0:e08:6373:dfc8 with SMTP id 3f1490d57ef6-e087048abb6mr4163517276.23.1721585080482; Sun, 21 Jul 2024 11:04:40 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:7256:0:b0:e05:fd7c:9d00 with SMTP id 3f1490d57ef6-e05fdb32a3cls6259620276.1.-pod-prod-08-us; Sun, 21 Jul 2024 11:04:39 -0700 (PDT) X-Received: by 2002:a05:690c:108:b0:61b:ebab:ce9b with SMTP id 00721157ae682-66a66a28873mr4781787b3.3.1721585079166; Sun, 21 Jul 2024 11:04:39 -0700 (PDT) Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18bms7b3; Sat, 20 Jul 2024 19:12:19 -0700 (PDT) X-Received: by 2002:a25:8043:0:b0:e02:c06f:1db8 with SMTP id 3f1490d57ef6-e087005e6bemr8717276.4.1721527938357; Sat, 20 Jul 2024 19:12:18 -0700 (PDT) Date: Sat, 20 Jul 2024 19:12:18 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <6d52892b-db6c-4497-894a-cc6f337acb97n@googlegroups.com> In-Reply-To: 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_530330_1096622603.1721527938131" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_530330_1096622603.1721527938131 Content-Type: multipart/alternative; boundary="----=_Part_530331_1569615936.1721527938131" ------=_Part_530331_1569615936.1721527938131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi dev0, > I will quote _willcl-ark_'s last comment as I do not have enough=20 permissions in bitcoin core repository to moderate comments: >=20 > "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 p> hilosophical discussion we are going to close and lock=20 this PR." I think you're missing my argument about formalization as ways to have=20 moderation norms shared and accepted by all contributors whatever, their cultural or professional background.=20 I believe (a) the moderation criteria on in / off-topic comment and its=20 exercise by moderator shall be objective enough to be understood and=20 spontaneously followed by contributors and (b) the moderators vetted with permissions=20 should adhere to a minimal of conflicts of interests guidelines to avoid=20 being accused of being "political" in the exercise of their permsisions (cf. bitcoin-meta= =20 issue #3 which I'll observe has been opened for 2 months now and have not= =20 received an answer). > A new pull request should help reviewers. If you do not agree with it,=20 feel free to discuss it with moderators in bitcoin core IRC channel. This is a non-sense to say a new pull request should help reviewers, when= =20 as a PR author you cannot know with certainty who will be the reviewers in= =20 a FOSS project like Core. About engaging on the moderation rules, like said, it's already done on the= =20 gituhb, which favors long-format and in-depth discussion (rather than an=20 IRC channel). > Related discussion: https://github.com/bitcoin-core/meta/issues/5 This is certainly a discussion that we shall have a community, be it=20 bitcoin core project active contributors, or security researchers offering= =20 their time to report sec issues. > Ironically, this is exactly how moderation works in bitcoin core pull=20 requests and some comments were marked off-topic.. I'll observe that we're quite limited by the medium itself, i.e github as= =20 we cannot prioritize review comments based on contributors reputation. Though this is not answering the risk of having an in / off-topic=20 moderation criteria inflating with time and vicissiating from intellectual= =20 substance the "public communication channels". If you look on the history of public space in the world over the last 2=20 millenias and what lessons we can drawn or ponder for FOSS development, a= =20 public space is always a frail notion that it always at risk of disappearing or being captured. I= =20 can always recommend you to read Hannah Arendet's The Crisis of Culture or= =20 The Human Condition if you wish to meditate on this notion of public space, and the significance= =20 of it (it's a philosopher I hope relatively universal, whatever your=20 cultural background). > 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 Interesting, I'll review it again in the coming future. Best, Antoine ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b4504907e02059e7a02046b6220dc2e Le samedi 20 juillet 2024 =C3=A0 07:51:09 UTC+1, /dev /fd0 a =C3=A9crit : > Hi Antoine, > > > I'm interested if you can propose a formal or mathematical definition= =20 > of 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 thi= s=20 > PR." > > A new pull request should help reviewers. If you do not agree with it,=20 > feel 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=20 > give 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=20 > piece 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=20 >> request to enable full RBF by default, referencing the one closed due to= =20 >> off-topic 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 situatio= n=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 giv= e=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 piec= e=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=20 >> wise to bundle it with novel >> technical information, as from the outset it does not favor to=20 >> concentrate 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: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fd= ab >> Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev /fd0 a =C3=A9cri= t : >> >>> 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 reques= t=20 >>> to enable full RBF by default, referencing the one closed due to off-to= pic=20 >>> comments.=20 >>> >>> > But read on, this is quite an odd case of Core politics, and the stor= y=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 includin= g=20 >>>> a fun=20 >>>> homework problem at the end: figure out how TRUC/V3 transactions itsel= f=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-rb= f=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=20 >>>> 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/812907c2b00b92ee31e2b638622a4fe14= a428aee/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, an= d=20 >>>> don't=20 >>>> want to admit that they've wasted a large amount of engineering time o= n=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-RB= F=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=20 >>>> work, you've=20 >>>> probably figured it out already based on the title: obviously, if a=20 >>>> high=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= =20 >>>> not 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 wil= l=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= =20 >>>> if 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.=20 >>>> Since=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 pa= y=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=20 >>>> less 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=20 >>>> 3sat/vB 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=20 >>>> about 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=20 >>>> 100KvB, 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=20 >>>> mining=20 >>>> consolidation transactions for them at low cost. In this variant of th= e=20 >>>> attack,=20 >>>> the attacker would pad the size of B with consolidation spends that=20 >>>> they 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=20 >>>> attack, 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,= =20 >>>> the=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/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.com. ------=_Part_530331_1569615936.1721527938131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi dev0,

> I will quote _willcl-ark_'s last comment as I do n= ot have enough permissions in bitcoin core repository to moderate comments:=
>
> "However the comments section here has become difficu= lt to follow due to numerous off-topic comments, a few personal disagreemen= ts, and repetition of arguments. In the interest of having a more productiv= e and focused technical and p> hilosophical discussion we are going to c= lose and lock this PR."

I think you're missing my argument about= formalization as ways to have moderation norms shared and accepted by all = contributors whatever, their
cultural or professional background.

I believe (a) the moderation criteria on in / off-topic comment and= its exercise by moderator shall be objective enough to be understood and s= pontaneously
followed by contributors and (b) the moderators vetted wi= th permissions should adhere to a minimal of conflicts of interests guideli= nes to avoid being accused
of being "political" in the exercise of the= ir permsisions (cf. bitcoin-meta issue #3 which I'll observe has been opene= d for 2 months now and have not received an answer).

> A new = pull request should help reviewers. If you do not agree with it, feel free = to discuss it with moderators in bitcoin core IRC channel.

This = is a non-sense to say a new pull request should help reviewers, when as a P= R author you cannot know with certainty who will be the reviewers in a FOSS= project like Core.
About engaging on the moderation rules, like said,= it's already done on the gituhb, which favors long-format and in-depth dis= cussion (rather than an IRC channel).

> Related discussion: h= ttps://github.com/bitcoin-core/meta/issues/5

This is certainly a= discussion that we shall have a community, be it bitcoin core project acti= ve contributors, or security researchers offering their time to report sec = issues.

> Ironically, this is exactly how moderation works in= bitcoin core pull requests and some comments were marked off-topic..
=
I'll observe that we're quite limited by the medium itself, i.e githu= b as we cannot prioritize review comments based on contributors reputation.=

Though this is not answering the risk of having an in / off-top= ic moderation criteria inflating with time and vicissiating from intellectu= al substance the "public communication channels".

If you look on= the history of public space in the world over the last 2 millenias and wha= t lessons we can drawn or ponder for FOSS development, a public space is al= ways
a frail notion that it always at risk of disappearing or being ca= ptured. I can always recommend you to read Hannah Arendet's The Crisis of C= ulture or The Human Condition if
you wish to meditate on this notion o= f public space, and the significance of it (it's a philosopher I hope relat= ively universal, whatever your cultural background).

> I have= opened a pull request with the same commits (Peter Todd being the author) = to enable Full RBF by default: https://github.com/bitcoin/bitcoin/pull/3049= 3

Interesting, I'll review it again in the coming future.
<= br />Best,
Antoine
ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b45= 04907e02059e7a02046b6220dc2e

Le samedi 20 juillet 2024 =C3=A0 07:51:09 UT= C+1, /dev /fd0 a =C3=A9crit=C2=A0:
Hi Antoine,

>=C2=A0 I'm interested if you can propose a formal or mathematical definition o= f what constitute
> an in-topic of off-topic comments on a matters li= ke full RBF, which has been controversial
> for like a decade.
I will quote _willcl-ark_'s last comment as I do not have e= nough permissions in bitcoin core repository to moderate comments:

"However the comments section here has become difficu= lt to follow due to numerous off-topic comments, a few personal disagreemen= ts, and repetition of arguments. In the interest of having a more productiv= e and focused technical and philosophical discussion we are going to close = and lock this PR."

A new pull request should = help reviewers. If you do not agree with it, feel free to discuss it with m= oderators in bitcoin core IRC channel.

= >=C2=A0 Again, I'm interested if you can propose a formal or mathematical defin= ition of what constitute
> a reasonable bitcoin core vulnerability ha= ndling 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 discussion:=C2=A0https://github.com/bitcoin-core/meta/issues/5=

>=C2=A0I think we have a mailing list to favorize te= xtual long format and encourage a more self-reflexive
> mode of reaso= ning in the conduct of bitcoin engineering discussions. I believe comments = not bringing
> new factual information or pointing to past experience= s or concrete piece of information are better
> left to twitter / nos= tr / reddit, whatever other communication channel where the scientific and<= br>> ethics of conversation standards are less stringent.

=
Ironically, this is exactly how moderation works in bitcoin core= pull requests and some comments were marked off-topic..

I have opened a pull request with the same commits (Peter Todd being= the author) to enable Full RBF by default:=C2=A0https://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 wr= ote:
Hi /dev/fd0
> The last comment in the pull request suggests opening a new pull req= uest to enable full RBF by default, referencing the one closed due to off-t= opic comments.

I'm interested if you can propose a formal or mat= hematical definition of what constitute
an in-topic of off-topic comment= s on a matters like full RBF, which has been controversial
for like a de= cade. I can only think such definition could make future conversations abou= t
the boundaries of what is in / off bitcoin engineering topic more obje= ctive.

> 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 in the recent words of
a group of some active contributo= rs:

"The project has historically done a poor job at publicly d= isclosing security-critical bugs, whether
externally reported or found b= y contributors. This has led to a situation where a lot of users perceiveBitcoin Core as never having bugs. This perception is dangerous and, unfo= rtunately, 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 rea= sonable bitcoin core vulnerability handling policy and that way give more g= round on qualifying
if a present situation is falling out of this reason= able guidelines and that can be qualified more
objectively as "pol= itics".

I think we have a mailing list to favorize textual long= format and encourage a more self-reflexive
mode of reasoning in the con= duct of bitcoin engineering discussions. I believe comments not bringingnew factual information or pointing to past experiences or concrete piece = of information are better
left to twitter / nostr / reddit, whatever oth= er communication channel where the scientific and
ethics of conversation= standards are less stringent.

All that said, I'm thinking to ag= ree that the usage of all political rhethoric is a fallacy better
left f= or expressions on other communication channels and this is note wise to bun= dle it with novel
technical information, as from the outset it does not = favor to concentrate the discussion on the fact
and logical reasoning th= emselves. Even more, political rhetoric very easily downgrade in moralistic=
contest among protagonists on who has the monopole of the good / truth.= Somehow bitcoin is beyond
good and evil (-- under some long-term and ab= stract perspective).

Best,
Antoine
ots hash: 3088507ecfb55ed30= 1bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
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 s= ubstantive
> response from Bitcoin Core, other than Core closing the = my pull-req enabling
> full-RBF by default that would fix this specif= ic vulnerability.

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
<= /div>

--
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/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.com.=
------=_Part_530331_1569615936.1721527938131-- ------=_Part_530330_1096622603.1721527938131--