From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 21 Jul 2024 11:04:53 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVavS-00029P-LU for bitcoindev@gnusha.org; Sun, 21 Jul 2024 11:04:53 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e0872023b7dsf3407755276.2 for ; Sun, 21 Jul 2024 11:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721585084; x=1722189884; 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=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=; b=nqwaA8S8Xj6/guypTlUudEUFzy4vkRVAHCbi6xTXZohgcq/HpCLERlm9/L8Flq07fB e0crtjfD9QdCQFqMjsBm6IefcW1mYWE8J76qboZtHTT3z9aFSDlNtYlxL8HXpGuqq34w Y+zQuSDRv2Oi8jDsWBSZk/rJICXozcRs5y0+3/MpAL5CYWjT+qlUtZAL15XJsk8E0t/W PvDIYX9fwJ0Ap/4h5IYFrJL1j0wwGdoT05LzEWXipB8vq0BIs85dYcRFRWSScG8ho25Z 4RPWQ1UhmI6Pi8zQGMTVwmhhoaO4JC7rdY0itsOgLbQ6J4d+EPHJ3IPDSoeItfNEgVHb Rl8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721585084; x=1722189884; 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=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=; b=FlFo3WysxVeOY64r4AH5eJa6Ygin95dh1096ghRZBAvZLs9zewpRxCP2RJxQR9s+k/ 0eEvmYr2CJhjXwiTIfAjN+BM4Cyjjfv9ce2zURLEhJDZSBa0bhx0fqsZAkX8KT27h816 PjrYosdUZzV4+Rqyme9Z2HB5r6jhVvOzw5SnJjnOKXqEWXDfkrCMoPOGj2iZlfuTXm1S Dim46FaEqQKyq+H0K/GZF0mTlCwxDLJNt7X6qX7EB5uUfH6h9cMrTi8FMCe07AGEuDlP zDe9bfR3hXN4XE4UW3nF+nWbmNq+Wevwh5xPSKTMrWYhBDgq7L97jWBaH8/ELf7dMdDe 9Tow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721585084; x=1722189884; 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=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=; b=eiL+/4JqqgBKT84tCJgAngIFgJL/K/Hz/EXOLSwIphT5bfXW5VTR6qLYqsi3h2jyul mi2uTl359+27/eopjzQMQ+t+MdNHb2zjh2ElypF+scwmL85CC95yuN9yDJ9h2OxdJFWs YnH7HXj0PTZ+/QmrxnQ0OzXqrQwzaRFcndLUCUQjSWEHJED5kiwRjnTaM0OSLLfDQevW CRq9+IY48TElbPzpQhwW27FHMHi6NoEFpO79Ih7bitw7hqwmw2Swbu3xkc3EarRymUrK zJnwA0vwciTpLvMe2a1tng5gts4jzquOfSjO7sT4oZsA1kk467myQobeGqOiFFkK73bR tTgA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXxhBYs+EAAxYhfxiNrefLjqB/mgEpXu1wXuF6CbawYOnS9skkLcjNmMM4/6Loi40sBGc3GPwWOJAkb1b6S2Fcp4qGgfIY= X-Gm-Message-State: AOJu0Ywg0ryEMn7kchhaKM7Awf44kbphCdxDYgzvEkPuezR9UMM85k77 e7grp7g0sTLFm/HyuRSmbYZvINBNyece4ydLtSFpsy+wdnILkZZQ X-Google-Smtp-Source: AGHT+IES56h2ywfhI6BU5jqhFUk/2LASP7t5CBEnoOMhVYwt/XFxP5yhuJ+RkR5tehOiuO20VsjRGQ== X-Received: by 2002:a05:6902:200b:b0:e08:726a:5a87 with SMTP id 3f1490d57ef6-e087b345739mr4375806276.4.1721585084436; Sun, 21 Jul 2024 11:04:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:870d:0:b0:e03:3e31:f7ca with SMTP id 3f1490d57ef6-e05fdd4eb6bls5303007276.2.-pod-prod-03-us; Sun, 21 Jul 2024 11:04:43 -0700 (PDT) X-Received: by 2002:a05:690c:398:b0:61b:e103:804d with SMTP id 00721157ae682-66a63b6c182mr630617b3.0.1721585083226; Sun, 21 Jul 2024 11:04:43 -0700 (PDT) Received: by 2002:a05:690c:2e0a:b0:64a:6fb4:b878 with SMTP id 00721157ae682-669195b3414ms7b3; Sat, 20 Jul 2024 19:10:55 -0700 (PDT) X-Received: by 2002:a05:690c:10d:b0:627:a671:8805 with SMTP id 00721157ae682-66a63f48814mr3491257b3.3.1721527853855; Sat, 20 Jul 2024 19:10:53 -0700 (PDT) Date: Sat, 20 Jul 2024 19:10:53 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_507422_1310615009.1721527853625" 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: 1.5 (+) ------=_Part_507422_1310615009.1721527853625 Content-Type: multipart/alternative; boundary="----=_Part_507423_1098517225.1721527853625" ------=_Part_507423_1098517225.1721527853625 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your thoughtful answer (even if its wasn't addressed to me=20 primarly). > I cannot imagine what would make you think that protocol developers are > not concerned about attacks that could drive large numbers of relay > nodes off the network for a cost easily affordable to any well-funded > adversary. >From my experience code reviewing the wallet / mempool re-broadcast of few years ago, free tx-relay / bandwidth waste attacks were far to be=20 understood=20 or plainly weighted by some contributors of a newer generations, including= =20 by the own champion of the proposal. The proposal was finally abandonned when = a more senior dev came up with quantitative analysis of code changes [0]. [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105 > In this case, you've found a specific instance (full-RBF vs signaled > RBF) of a well-known general problem (optional policies leading to > mempool inconsistencies, allowing free relay) and appear to be arguing > that devs don't care about free relay because they refused to reverse a > previous decision (to not change the RBF configuration default) that has > been hotly debated multiple times. I think what is more interesting and noteworhty in the whole line of=20 reaosning of Peter with the present disclosure is how much the adversial effect is=20 favor by the supermajority of miners running `mempoolfullrbf` [1]. [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316 That Peter's sample calls for empirical measures of their own by other=20 contributors=20 that can only make the whole review process and consensus-building towards= =20 a change or the status quo better. Being able to empirically measure how bitcoin=20 full-node software is practically used by end-users, be it miners, second-layers=20 nodes, simple coins wallet users, exchanges, and making that a protocol development=20 standard I believe that how we progress as an ecosystem. > An alternative interpretation is that they (1) do care about free relay, > (2) recognize that solving free relay is a hard problem that requires > research and development, and (3) refuse to be forced into restarting > debate on an already overdiscussed issue that gets nobody closer to > fundamental solutions. The strong statement we have from the bitcoin core about attacks and=20 vulnerabilities mitigation, which probably represents the viewpoint of many generation of contributors is the following as old than few weeks ago: "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=20 situation where a lot of users perceive Bitcoin Core as never having bugs. This perception is=20 dangerous and,=20 unfortunately, not accurate." [2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w Under those conditions, where it took 9 years for the bitcoin core project= =20 to disclosre some vulnerabilitires, personally I'm more likely to understand that the=20 bitcoin core project is under-staffed is competent experts to keep public disclosure in=20 reasonable timeframe (-- at least equivalent to the kernel world), and as corollorary to fully evaluate= =20 technical proposal with all its strength and weaknesses. Saying an "already overdiscussed issues that gets nobody closer to=20 fundamental solutions" is insulting for Peter, honestly. > Many protocol developers have attempted to address the problem over the= =20 years, most recently just > a few months ago with an updated proposal for using weak blocks as a=20 first step to address > "diverging mempool policies".[1] With all my respect for the developers involved in the design of this=20 proposal who are skilled bitcoin engineers in themsleves, I think betting on the "weak blocks" idea is a=20 dead end in itself as in relying on the slow convergence idea, that it's at the heart of the ghost, block=20 dag and other ideas we've seen 10 years ago to make mining income "more fair" among geographically=20 distributed mining pools. I conjecture, it's a dead end as you will more or less have to re-build a= =20 secondary consensus algorithm in the block-relay stack or in the mining stack, which is going to run=20 intou its own mempool convergence issues again, in a recursive fashion. I believe such proposal is more an instance of the ill-managed conflict of= =20 interest blockstream-style syndrom that bitcoin protocol devs, who ever they care can be affected=20 with. In the present instance: "My employer has gained a commercial interest in mining business recently= =20 so now let's advocate a very complex bitcoin p2p protocol changes, rather than humbly realize that=20 mining economic units are more akin to a traditional energy company which not really in the less than 2-decades= =20 corporate DNA of said employer, and why actually the economic units results of our mining division are=20 floppy and now we engage in bitcoin core changes at our advantage" (in my own reasonable view -- though I can= =20 only invite the "weak block" employer company corporate board to comment here if they diverge on my analysis). >From a more pure technical viewpoint, I think bitcoin core compact blocks= =20 block-relay handling code, after 7 years of having been merged in bitcoin core has still `TODO` left in the= =20 codebase, and it could be an area worhty of more testing / cleaning refactoring, I'm just saying by the way. > You've previously argued against designing contract protocols to depend= =20 > CPFP-style fee bumping for their offchain transactions, however that is= =20 > what is widely used by LN today and it appears to be what LN and other=20 > offchain protocol developers want to use in the future. If we accept=20 > that, at least for the purposes of argument, what can we do to improve=20 > CPFP fee bumping for LN?=20 As an offchain protocol developers which has been involved in the majority= =20 of technical conversations, implementations and deployment of the "anchor output" upgrade, I believe on= =20 the long-term CPFP-style fee-bumping of contract protocol, including lighting, is not the most robust technical= =20 solutions. I think anyone can check in the bitcoin optech anchor output glossary the numerous vulnerabilities= =20 that have plagued this fee-bumping=20 solutions over the past years. Pursuing on that trend will more only probably lead to a current state of= =20 what we have with DNS / BGP at the internet-stack level, which are still constantly the sources of new=20 security vulnerabilitiies and single-point of-failure securiyt solutions like X509 certificates management (do we wish= =20 bitcoin to be plagued by crowdstyle technical incident 15 years from now ? I'm not so sure). > All we really need at this point is to enable package relay so that=20 > parent transactions are no longer subject to a dynamic mempool minimum=20 > when they're bundled with a high-feerate child. Preliminary support for= =20 > that should be released in the next major version of Bitcoin Core, with= =20 > improved support being worked on for later releases.=20 >=20 > Package relay is the only thing we need at this point because the=20 > existing LN protocol makes use of CPFP carve-out, which minimizes=20 > transaction pinning issues.=20 I don't disagree on package relay deployment at this stage, with the some= =20 degree of technical skeptiscism that shall accomaphny all p2p proposals. Let's remember things that have=20 been rollback or slowly rollout like bip37 or `MEMPOOL` p2p message. > However, another substantial Bitcoin Core improvement, cluster mempool,= =20 > is incompatible with CPFP carve-out. TRUC is an alternative to CPFP=20 > carve-out that is easy to reason about, easy to use, more general in=20 > nature (good news for newer contract protocols), and which can possibly= =20 > be automatically applied to existing LN onchain transactions, allowing=20 > cluster mempool to be deployed ASAP without requiring any significant=20 > changes to anyone else's software.=20 If you or anoyone think TRUC as an alternative to the CPFP as a transsction= =20 pinning mitigation as argued in its merged BIP is easy to reason on, thanks to communicate your=20 lightning node pubkey, with TRUC patch applied and a GPG-signed message authorizing me to demonstrate the security= =20 properties of this solutions have not been submitted to a fully contradictory evaluation. I pointed out few years ago that relying on mempool-policy changes as a=20 fully hardening solution was very likely limited to mitigate econommical-based pinnings (i.e bip125 absolute= =20 fee rule), and this was before the discovery of new transaction-relay jamming vector (a terminology=20 catched by your himself in some private conversation if my memory is correct) like replacement cycling=20 attacks [4]. [4]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019084.ht= ml=20 "high-half" in this post corresponds to what roughly is bip331 today. > I don't think we need to be overly concerned about large numbers of LN=20 users suddenly performing a malicious > action that does not benefit them and does not put the network at risk. Have a look on base-layer based exploitation description that could provoke= =20 a large number of LN users, without their own involvement, that could put the base-network at risk [5]. [5]=20 https://github.com/jamesob/mempool.work?tab=3Dreadme-ov-file#failure-one-me= mpool-to-rule-them-all > The alternative to TRUC that you've proposed is replace-by-feerate=20 > (RBFr). This is also compatible with existing LN transactions and it's=20 > conceptually super simple (I assume the code is too), which is=20 > wonderful. However, it's downsides are:=20 About replace-by-feerate, I think it's a solution that have downside on its= =20 own, especially for second-layers like lightning. I never took time to write a canonical post= =20 as infosec ethics would ask me to notice lightning maininters to do first, even if the vulnerability=20 idea has been vaguely sketched out to few years ago. On all your replace-by-feerate analysis, I think it deserves a thread on=20 its own, as somehow the issue can have interactions with degree of fulfillness of miner block templates,= =20 a conversation we had when V3 was proposed as solution [6]. [6]=20 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817= .html=20 and following answers > but the deployment of cluster mempool requires removal of CPFP carve-out,= =20 and removal of CPFP carve-out requires > either the upgrade of thousands of LN nodes and channels or a drop-in=20 solution (ideally one that can be analyzed=20 > independently from cluster mempool, like TRUC) And as I observed on one of the V3 PR threads and corresponding=20 conversations, the CPFP carve-out do not provide security to lightning implementation as (a) old revoked commitment=20 transactions can be used to fail the CPFP bump, V3 or not V3 and (b) there is no base-layer p2p protocol discovery of txids= =20 [6]. And I won't observe that when I looked on lightning implementations code, only Eclair have minimal correct=20 implementation of remote valid commitment transactions broadcast, not the other one as it's not even in the bolt spec. [6] https://github.com/bitcoin/bitcoin/pull/28948 So unless someone argued to the contrary, saying TRUC was needed to then=20 deploy cluster mempool is an intellectual fallacy, of which the origin could likely arises from the back macket of PR= =20 reviews trading happening in the bitcoin core project for people to advance their own pet projects. At the very least,=20 from my own code review of the folks bitcoin core PR related to this line of deployment you're exposing, I'm not sure=20 they're understanding so well cross-layers issues [7]. [7] https://github.com/bitcoin/bitcoin/pull/29427 I think you're rather making the points that the current group of most=20 active bitcoin core contributors, are indeed skilled bitcoin engineers, vetted with project-management know-how and=20 informed about bitcoin technical history and know how to stay polite and civil (most of the time) to create a fruitful=20 technical conversation atmosphere. They're not necessarily the most astute and adversarial minds to spot on the flight the weakness of= =20 new technical proposals, neither with the character to say so _at the cost_ of sometimes being rude and negative in the=20 communication tone. And this in line with my point above recalling that the bitcoin core group of people themselves estimate=20 themsleves they don't do a good job in term of security vulnerabilties handling. > There have already been multiple public discussions about how improved=20 > RBF policies can be implemented once cluster mempool is available, many= =20 > of which bring us closer to something like RBFr in a way that's easier=20 > to prove won't enable free relay, and perusing that seems to me like a=20 > productive outlet if you are interested.=20 I already reviewed some parts of cluster mempool. Fundamentally, economical= =20 mempool pinnings for second-layers (bip125 absolute fee) with pre-signed time-sensitive transactions arises from a world where= =20 there is (a) an asynchronicity of mempools and (b) one cannot guess feerates at block + 1 (-- let's say in a deterministic fashion= =20 as understood by traditional cryptographic litterature when doing cryptanalysis). Better RBF policies won't solve that, including= =20 RBFr. > After several hours of writing and thinking, I don't see any problems > with the current approach using TRUC or with the general lack of > interest in RBFr solutions at this time. I've tried to explain how I > arrived at my conclusions at each step and I welcome any corrections. On my personal perspective, and after careful considerations of all the=20 technical points you've raised. I still think TRUC has a lot of problems. RBRFr too has technical problems. About TRUC I think= =20 it's an acceptable temporary solution to minimize the pinning surface of lightning implementations, pending for the design of= =20 a better solution (more likely at the consensus-level, here consistently as I pointed out 3 years ago). Though we shall be honest= =20 with ourselves and not engage in overdue security theater about TRUC properties. To finish, I'll re-assert what is my appreciation. Currently, I don't think= =20 the bitcoin core folks handling the security list has necessarily the proven level of competency to fully evaluate the issues=20 reported by Peter, however I don't believe in the present case they have done anything wrong infosec ethically-wise. Best, Antoine ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e7a3d65b256caa7 Le samedi 20 juillet 2024 =C3=A0 07:45:24 UTC+1, David A. Harding a =C3=A9c= rit : > On 2024-07-18 05:56, Peter Todd wrote: > > I disclosed it to the bitcoin-security mailing list as a test: does > > Bitcoin Core actually care about free relay attacks? > > They do. Several free relay attacks that were present in earlier > versions of Bitcoin were eliminated in later versions. New proposals > are evaluated for their potential to create new permanent free relay > vectors. The discovery of free relay is almost always reason enough to > reject a proposal. > > The free relay attack you describe in your email and the type of free > relay enabled by your replace-by-feerate (RBFr) proposal can allow an > attacker to 10x to 100x the amount of bandwidth used network wide by > relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention, > effectively for free if they were going to send a bunch of transactions > anyway). > > I cannot imagine what would make you think that protocol developers are > not concerned about attacks that could drive large numbers of relay > nodes off the network for a cost easily affordable to any well-funded > adversary. > > In this case, you've found a specific instance (full-RBF vs signaled > RBF) of a well-known general problem (optional policies leading to > mempool inconsistencies, allowing free relay) and appear to be arguing > that devs don't care about free relay because they refused to reverse a > previous decision (to not change the RBF configuration default) that has > been hotly debated multiple times. > > An alternative interpretation is that they (1) do care about free relay, > (2) recognize that solving free relay is a hard problem that requires > research and development, and (3) refuse to be forced into restarting > debate on an already overdiscussed issue that gets nobody closer to > fundamental solutions. > > > I believe the authors of that BIP are fully aware of the fact that > > "free" relay is an unavoidable problem, making their rational for > > TRUC/V3 bogus > > Differences in node policy leading to mempool inconsistencies (which > allows free relay) is a well known problem that's the result of Bitcoin > being an open protocol based on free/libre software (two things I think > we all want). Many protocol developers have attempted to address the > problem over the years, most recently just a few months ago with an > updated proposal for using weak blocks as a first step to address > "diverging mempool policies".[1] > > A currently unsolved problem is not necessarily an unavoidable problem > and it seems reasonable to me for devs to be skeptical of proposals like > RBFr that add to the list of things that enable free relay. > > > I believe the authors of [BIP431...] don't want to admit that they've > > wasted a large amount of engineering time on a bad proposal. > > You've previously argued against designing contract protocols to depend > CPFP-style fee bumping for their offchain transactions, however that is > what is widely used by LN today and it appears to be what LN and other > offchain protocol developers want to use in the future. If we accept > that, at least for the purposes of argument, what can we do to improve > CPFP fee bumping for LN? > > All we really need at this point is to enable package relay so that > parent transactions are no longer subject to a dynamic mempool minimum > when they're bundled with a high-feerate child. Preliminary support for > that should be released in the next major version of Bitcoin Core, with > improved support being worked on for later releases. > > Package relay is the only thing we need at this point because the > existing LN protocol makes use of CPFP carve-out, which minimizes > transaction pinning issues. > > However, another substantial Bitcoin Core improvement, cluster mempool, > is incompatible with CPFP carve-out. TRUC is an alternative to CPFP > carve-out that is easy to reason about, easy to use, more general in > nature (good news for newer contract protocols), and which can possibly > be automatically applied to existing LN onchain transactions, allowing > cluster mempool to be deployed ASAP without requiring any significant > changes to anyone else's software. > > As you've shown[2], the main downside of TRUC transactions (if we're > going to depend on CPFP-style fee bumping anyway) is that users of TRUC > transactions who have a malicious counterparty might need to pay a > slightly higher onchain feerate than they would need to pay under the > same situation with CPFP carve-out. However, the increase is small > enough that most honest parties should be able to afford it, so there's > no incentive for a counterparty to do it. I don't think we need to be > overly concerned about large numbers of LN users suddenly performing a > malicious action that does not benefit them and does not put the network > at risk. > > The alternative to TRUC that you've proposed is replace-by-feerate > (RBFr). This is also compatible with existing LN transactions and it's > conceptually super simple (I assume the code is too), which is > wonderful. However, it's downsides are: > > 1. It fundamentally enables a significant amount of free relay. I'll > sketch a super basic attack at the end of this email that costs 0.55 > BTC per day ($67,000 USD) to 100x the amount of bandwidth used by > relay nodes. I'm sure more efficient attacks are possible. > > An attacker who is able to consume an excessive amount of relay node > bandwidth at relatively low cost may be able to create both > short-term and long-term problems for all Bitcoin users. If the > created problems result in a rapid increase in user feerates, then > free relay attacks become cheaper due to low feerate transactions > being automatically evicted from the bottom of the mempool. > > 2. It may allow empting the mempool at relatively low cost. An attacker > sending just 750 transactions at the top mempool feerate can > guarantee eviction of every honest user's transactions. The attacker > can then replace 300 MB of transactions with a single 43,179 vbyte > transaction. Even if the replacement transaction pays 100 > sats/vbyte, when you compare that to the 1,000,000 vbytes of > next-block transactions each miner lost, the miner is only earning an > effective feerate of 4.3 sats/vbyte. > > Further, it's easy to imagine situations where evicting > time-sensitive transactions from mempools might allow theft of funds > in excess of a few thousand dollars (my immediate thoughts go to > situations involving watchtowers). > > 3. Limiting the worst-case free relay and excessive mempool eviction > requires additional rules (e.g. one-shot RBFr) that are challenging > to implement and analyze at present, as several devs have noted[3]. > Both implementation and analysis should become much easier if cluster > mempool is deployed (also noted by devs), but the deployment of > cluster mempool requires removal of CPFP carve-out, and removal of > CPFP carve-out requires either the upgrade of thousands of LN nodes > and channels or a drop-in solution (ideally one that can be analyzed > independently from cluster mempool, like TRUC). > > To me, TRUC seems like an excellent approach. It's something that can > be evaluated independently of cluster mempool but which can help allow > that deployment to proceed (in addition to the other previously > described benefits that TRUC brings). > > There have already been multiple public discussions about how improved > RBF policies can be implemented once cluster mempool is available, many > of which bring us closer to something like RBFr in a way that's easier > to prove won't enable free relay, and perusing that seems to me like a > productive outlet if you are interested. > > > this is quite an odd case of Core politics > > I began writing this reply to force me to examine your claims for > myself. You have a long history of noticing things other people missed. > I was worried that some compelling point of yours was being ignored as > the result of past controversies. > > After several hours of writing and thinking, I don't see any problems > with the current approach using TRUC or with the general lack of > interest in RBFr solutions at this time. I've tried to explain how I > arrived at my conclusions at each step and I welcome any corrections. > > Thanks, > > -Dave > > [1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805 > [2]=20 > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022= 211.html > [3]=20 > > https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by= -feerate-to-escape-pinning > > --- > A simple free relay attack using RBFr > > ## Constants > > 100,000 vbytes =3D=3D ~400,000 bytes > A 1-input, 1-output P2TR scriptpath spend with the maximum amount > of witness data allowed by Bitcoin Core defaults > > 111 vbytes =3D=3D 162 bytes > A 1-input, 1-output P2TR keypath spend > > ## Attack > > - Attacker obtains 500,000 UTXOs > > - For each UTXO > > - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000 > byte) transacton. > > - Waits for it to propagate. > > - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement > that is 111 vbytes (162 bytes). > > ## Analysis > > - At 162 bytes each, 500,000 transactions is 81 MB. I think that will > fit in a default-sized mempool. > > - The total amount of transaction data relayed is 500_000 * (400_000 + > 162), or about 200 GB. > > - The typical daily bandwidth requirement of a blocks-only node is > roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying > node is about the same due to compact blocks, but realistically, it's > a small multiple of that. Call it 2 GB per day. > > - This implies the attack push each RBFr relay node to use 100x a > non-RBFr relay node. > > - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At > my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats, > or 0.55 BTC (about $37,000 USD). > > - This analysis ignores the cost of obtaining the UTXOs and possibly > later consolidating them, but it also ignores some easy optimizations > such as batching the replacements. > --=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/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com. ------=_Part_507423_1098517225.1721527853625 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for your thoughtful answer (even if its wa= sn't addressed to me primarly).

> I cannot imagine what would= make you think that protocol developers are
> not concerned about = attacks that could drive large numbers of relay
> nodes off the net= work for a cost easily affordable to any well-funded
> adversary.
From my experience code reviewing the wallet / mempool re-broadca= st of few
years ago, free tx-relay / bandwidth waste attacks were far = to be understood
or plainly weighted by some contributors of a newer = generations, including by
the own champion of the proposal. The propos= al was finally abandonned when a
more senior dev came up with quantita= tive analysis of code changes [0].

[0] https://github.com/bitcoi= n/bitcoin/pull/21061#issuecomment-851563105

> In this case, y= ou've found a specific instance (full-RBF vs signaled
> RBF) of a w= ell-known general problem (optional policies leading to
> mempool i= nconsistencies, allowing free relay) and appear to be arguing
> tha= t devs don't care about free relay because they refused to reverse a
&= gt; previous decision (to not change the RBF configuration default) that ha= s
> been hotly debated multiple times.

I think what is m= ore interesting and noteworhty in the whole line of reaosning
of Peter= with the present disclosure is how much the adversial effect is favor
by the supermajority of miners running `mempoolfullrbf` [1].

[1= ] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316

That Peter's sample calls for empirical measures of their own by other con= tributors
that can only make the whole review process and consensus-b= uilding towards a change
or the status quo better. Being able to empir= ically measure how bitcoin full-node
software is practically used by e= nd-users, be it miners, second-layers nodes, simple
coins wallet users= , exchanges, and making that a protocol development standard I believe
that how we progress as an ecosystem.

> An alternative inter= pretation is that they (1) do care about free relay,
> (2) recogniz= e that solving free relay is a hard problem that requires
> researc= h and development, and (3) refuse to be forced into restarting
> de= bate on an already overdiscussed issue that gets nobody closer to
>= fundamental solutions.

The strong statement we have from the bi= tcoin core about attacks and vulnerabilities
mitigation, which probabl= y represents the viewpoint of many generation of
contributors is the f= ollowing as old than few weeks ago:

"The project has historicall= y done a poor job at publicly disclosing security-critical bugs,
wheth= er externally reported or found by contributors. This has led to a situatio= n where a lot
of users perceive Bitcoin Core as never having bugs. Thi= s perception is dangerous and,
unfortunately, not accurate."
[2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Unde= r those conditions, where it took 9 years for the bitcoin core project to d= isclosre
some vulnerabilitires, personally I'm more likely to understa= nd that the bitcoin core project
is under-staffed is competent experts= to keep public disclosure in reasonable timeframe (-- at
least equiva= lent to the kernel world), and as corollorary to fully evaluate technical p= roposal
with all its strength and weaknesses.

Saying an "al= ready overdiscussed issues that gets nobody closer to fundamental solutions= " is
insulting for Peter, honestly.

> Many protocol deve= lopers have attempted to address the problem over the years, most recently = just
> a few months ago with an updated proposal for using weak blo= cks as a first step to address
> "diverging mempool policies".[1]
With all my respect for the developers involved in the design of = this proposal who are skilled bitcoin
engineers in themsleves, I think= betting on the "weak blocks" idea is a dead end in itself as in relyingon the slow convergence idea, that it's at the heart of the ghost, block= dag and other ideas we've seen
10 years ago to make mining income "mo= re fair" among geographically distributed mining pools.

I conjec= ture, it's a dead end as you will more or less have to re-build a secondary= consensus algorithm
in the block-relay stack or in the mining stack, = which is going to run intou its own mempool convergence
issues again, = in a recursive fashion.

I believe such proposal is more an insta= nce of the ill-managed conflict of interest blockstream-style
syndrom = that bitcoin protocol devs, who ever they care can be affected with. In the= present instance:

"My employer has gained a commercial interest= in mining business recently so now let's advocate a very
complex bitc= oin p2p protocol changes, rather than humbly realize that mining economic u= nits are more akin
to a traditional energy company which not really in= the less than 2-decades corporate DNA of said employer,
and why actua= lly the economic units results of our mining division are floppy and now we= engage in bitcoin
core changes at our advantage" (in my own reasonabl= e view -- though I can only invite the "weak block" employer
company c= orporate board to comment here if they diverge on my analysis).

= >From a more pure technical viewpoint, I think bitcoin core compact blocks b= lock-relay handling code, after
7 years of having been merged in bitco= in core has still `TODO` left in the codebase, and it could be an area
worhty of more testing / cleaning refactoring, I'm just saying by the way.=

> You've previously argued against designing contract protoc= ols to depend
> CPFP-style fee bumping for their offchain transact= ions, however that is
> what is widely used by LN today and it app= ears to be what LN and other
> offchain protocol developers want t= o use in the future. If we accept
> that, at least for the purpose= s of argument, what can we do to improve
> CPFP fee bumping for LN= ?

As an offchain protocol developers which has been involved in= the majority of technical conversations,
implementations and deployme= nt of the "anchor output" upgrade, I believe on the long-term CPFP-style fe= e-bumping
of contract protocol, including lighting, is not the most ro= bust technical solutions. I think anyone can check
in the bitcoin opte= ch anchor output glossary the numerous vulnerabilities that have plagued th= is fee-bumping
solutions over the past years.

Pursuing on = that trend will more only probably lead to a current state of what we have = with DNS / BGP at the
internet-stack level, which are still constantly= the sources of new security vulnerabilitiies and single-point
of-fail= ure securiyt solutions like X509 certificates management (do we wish bitcoi= n to be plagued by crowdstyle
technical incident 15 years from now ? I= 'm not so sure).

> All we really need at this point is to ena= ble package relay so that
> parent transactions are no longer subj= ect to a dynamic mempool minimum
> when they're bundled with a hig= h-feerate child. Preliminary support for
> that should be released= in the next major version of Bitcoin Core, with
> improved suppor= t being worked on for later releases.
>
> Package relay i= s the only thing we need at this point because the
> existing LN p= rotocol makes use of CPFP carve-out, which minimizes
> transaction= pinning issues.

I don't disagree on package relay deployment a= t this stage, with the some degree of technical skeptiscism
that shall= accomaphny all p2p proposals. Let's remember things that have been rollbac= k or slowly rollout like
bip37 or `MEMPOOL` p2p message.

&g= t; However, another substantial Bitcoin Core improvement, cluster mempool, =
> is incompatible with CPFP carve-out. TRUC is an alternative to C= PFP
> carve-out that is easy to reason about, easy to use, more ge= neral in
> nature (good news for newer contract protocols), and wh= ich can possibly
> be automatically applied to existing LN onchain= transactions, allowing
> cluster mempool to be deployed ASAP with= out requiring any significant
> changes to anyone else's software.=

If you or anoyone think TRUC as an alternative to the CPFP as = a transsction pinning mitigation as argued
in its merged BIP is easy t= o reason on, thanks to communicate your lightning node pubkey, with TRUC pa= tch
applied and a GPG-signed message authorizing me to demonstrate the= security properties of this solutions have
not been submitted to a fu= lly contradictory evaluation.

I pointed out few years ago that r= elying on mempool-policy changes as a fully hardening solution was very
likely limited to mitigate econommical-based pinnings (i.e bip125 absolut= e fee rule), and this was before
the discovery of new transaction-rela= y jamming vector (a terminology catched by your himself in some
privat= e conversation if my memory is correct) like replacement cycling attacks [4= ].

[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= 021-June/019084.html "high-half" in this post
corresponds to what roug= hly is bip331 today.

> I don't think we need to be overly con= cerned about large numbers of LN users suddenly performing a malicious
> action that does not benefit them and does not put the network at ris= k.

Have a look on base-layer based exploitation description that= could provoke a large number of LN users, without
their own involveme= nt, that could put the base-network at risk [5].

[5] https://git= hub.com/jamesob/mempool.work?tab=3Dreadme-ov-file#failure-one-mempool-to-ru= le-them-all

> The alternative to TRUC that you've proposed is= replace-by-feerate
> (RBFr). This is also compatible with existin= g LN transactions and it's
> conceptually super simple (I assume t= he code is too), which is
> wonderful. However, it's downsides are= :

About replace-by-feerate, I think it's a solution that have d= ownside on its own, especially for
second-layers like lightning. I nev= er took time to write a canonical post as infosec ethics would ask
me = to notice lightning maininters to do first, even if the vulnerability idea = has been vaguely sketched
out to few years ago.

On all your= replace-by-feerate analysis, I think it deserves a thread on its own, as s= omehow the issue
can have interactions with degree of fulfillness of m= iner block templates, a conversation we had when V3
was proposed as so= lution [6].

[6] https://lists.linuxfoundation.org/pipermail/bitc= oin-dev/2022-January/019817.html and following answers

> but = the deployment of cluster mempool requires removal of CPFP carve-out, and r= emoval of CPFP carve-out requires
> either the upgrade of thousands= of LN nodes and channels or a drop-in solution (ideally one that can be an= alyzed
> independently from cluster mempool, like TRUC)

And as I observed on one of the V3 PR threads and corresponding conversati= ons, the CPFP carve-out do not provide
security to lightning implement= ation as (a) old revoked commitment transactions can be used to fail the CP= FP bump,
V3 or not V3 and (b) there is no base-layer p2p protocol disc= overy of txids [6]. And I won't observe that when I looked
on lightnin= g implementations code, only Eclair have minimal correct implementation of = remote valid commitment transactions
broadcast, not the other one as i= t's not even in the bolt spec.

[6] https://github.com/bitcoin/bi= tcoin/pull/28948

So unless someone argued to the contrary, sayin= g TRUC was needed to then deploy cluster mempool is an intellectual
fa= llacy, of which the origin could likely arises from the back macket of PR r= eviews trading happening in the bitcoin core
project for people to adv= ance their own pet projects. At the very least, from my own code review of = the folks bitcoin
core PR related to this line of deployment you're ex= posing, I'm not sure they're understanding so well cross-layers issues [7].=

[7] https://github.com/bitcoin/bitcoin/pull/29427

I = think you're rather making the points that the current group of most active= bitcoin core contributors, are indeed
skilled bitcoin engineers, vett= ed with project-management know-how and informed about bitcoin technical hi= story and know
how to stay polite and civil (most of the time) to crea= te a fruitful technical conversation atmosphere. They're not necessarilythe most astute and adversarial minds to spot on the flight the weakness= of new technical proposals, neither with the character
to say so _at = the cost_ of sometimes being rude and negative in the communication tone. A= nd this in line with my point above
recalling that the bitcoin core gr= oup of people themselves estimate themsleves they don't do a good job in te= rm of security
vulnerabilties handling.

> There have alr= eady been multiple public discussions about how improved
> RBF pol= icies can be implemented once cluster mempool is available, many
>= of which bring us closer to something like RBFr in a way that's easier > to prove won't enable free relay, and perusing that seems to me lik= e a
> productive outlet if you are interested.

I alrea= dy reviewed some parts of cluster mempool. Fundamentally, economical mempoo= l pinnings for second-layers (bip125 absolute
fee) with pre-signed tim= e-sensitive transactions arises from a world where there is (a) an asynchro= nicity of mempools and (b) one
cannot guess feerates at block + 1 (-- = let's say in a deterministic fashion as understood by traditional cryptogra= phic litterature
when doing cryptanalysis). Better RBF policies won't = solve that, including RBFr.

> After several hours of writing = and thinking, I don't see any problems
> with the current approach = using TRUC or with the general lack of
> interest in RBFr solutions= at this time. I've tried to explain how I
> arrived at my conclusi= ons at each step and I welcome any corrections.

On my personal p= erspective, and after careful considerations of all the technical points yo= u've raised. I still think TRUC
has a lot of problems. RBRFr too has t= echnical problems. About TRUC I think it's an acceptable temporary solution= to minimize
the pinning surface of lightning implementations, pending= for the design of a better solution (more likely at the consensus-level,here consistently as I pointed out 3 years ago). Though we shall be hon= est with ourselves and not engage in overdue security theater
about TR= UC properties.

To finish, I'll re-assert what is my appreciation= . Currently, I don't think the bitcoin core folks handling the security lis= t has
necessarily the proven level of competency to fully evaluate the= issues reported by Peter, however I don't believe in the present
case= they have done anything wrong infosec ethically-wise.

Best,
Antoine
ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e= 7a3d65b256caa7

Le samedi 20 juillet 2024 =C3=A0 07:45:24 UTC+1, David A. = Harding a =C3=A9crit=C2=A0:
On 2024-07-18 05:56, Peter Todd wrote:
> I disclosed it to the bitcoin-security mailing list as a test: doe= s
> Bitcoin Core actually care about free relay attacks?

They do. Several free relay attacks that were present in earlier
versions of Bitcoin were eliminated in later versions. New proposals
are evaluated for their potential to create new permanent free relay
vectors. The discovery of free relay is almost always reason enough to
reject a proposal.

The free relay attack you describe in your email and the type of free
relay enabled by your replace-by-feerate (RBFr) proposal can allow an
attacker to 10x to 100x the amount of bandwidth used network wide by
relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
effectively for free if they were going to send a bunch of transactions
anyway).

I cannot imagine what would make you think that protocol developers are
not concerned about attacks that could drive large numbers of relay
nodes off the network for a cost easily affordable to any well-funded
adversary.

In this case, you've found a specific instance (full-RBF vs signale= d
RBF) of a well-known general problem (optional policies leading to
mempool inconsistencies, allowing free relay) and appear to be arguing
that devs don't care about free relay because they refused to rever= se a
previous decision (to not change the RBF configuration default) that ha= s
been hotly debated multiple times.

An alternative interpretation is that they (1) do care about free relay= ,
(2) recognize that solving free relay is a hard problem that requires
research and development, and (3) refuse to be forced into restarting
debate on an already overdiscussed issue that gets nobody closer to
fundamental solutions.

> I believe the authors of that BIP are fully aware of the fact that
> "free" relay is an unavoidable problem, making their rat= ional for
> TRUC/V3 bogus

Differences in node policy leading to mempool inconsistencies (which
allows free relay) is a well known problem that's the result of Bit= coin
being an open protocol based on free/libre software (two things I think
we all want). Many protocol developers have attempted to address the
problem over the years, most recently just a few months ago with an
updated proposal for using weak blocks as a first step to address
"diverging mempool policies".[1]

A currently unsolved problem is not necessarily an unavoidable problem
and it seems reasonable to me for devs to be skeptical of proposals lik= e
RBFr that add to the list of things that enable free relay.

> I believe the authors of [BIP431...] don't want to admit that = they've
> wasted a large amount of engineering time on a bad proposal.

You've previously argued against designing contract protocols to de= pend
CPFP-style fee bumping for their offchain transactions, however that is
what is widely used by LN today and it appears to be what LN and other
offchain protocol developers want to use in the future. If we accept
that, at least for the purposes of argument, what can we do to improve
CPFP fee bumping for LN?

All we really need at this point is to enable package relay so that
parent transactions are no longer subject to a dynamic mempool minimum
when they're bundled with a high-feerate child. Preliminary suppor= t for
that should be released in the next major version of Bitcoin Core, with
improved support being worked on for later releases.

Package relay is the only thing we need at this point because the
existing LN protocol makes use of CPFP carve-out, which minimizes
transaction pinning issues.

However, another substantial Bitcoin Core improvement, cluster mempool,
is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
carve-out that is easy to reason about, easy to use, more general in
nature (good news for newer contract protocols), and which can possibly
be automatically applied to existing LN onchain transactions, allowing
cluster mempool to be deployed ASAP without requiring any significant
changes to anyone else's software.

As you've shown[2], the main downside of TRUC transactions (if we&#= 39;re
going to depend on CPFP-style fee bumping anyway) is that users of TRUC
transactions who have a malicious counterparty might need to pay a
slightly higher onchain feerate than they would need to pay under the
same situation with CPFP carve-out. However, the increase is small
enough that most honest parties should be able to afford it, so there&#= 39;s
no incentive for a counterparty to do it. I don't think we need to= be
overly concerned about large numbers of LN users suddenly performing a
malicious action that does not benefit them and does not put the networ= k
at risk.

The alternative to TRUC that you've proposed is replace-by-feerate
(RBFr). This is also compatible with existing LN transactions and it&#= 39;s
conceptually super simple (I assume the code is too), which is
wonderful. However, it's downsides are:

1. It fundamentally enables a significant amount of free relay. I'= ll
sketch a super basic attack at the end of this email that costs 0.5= 5
BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
relay nodes. I'm sure more efficient attacks are possible.

An attacker who is able to consume an excessive amount of relay nod= e
bandwidth at relatively low cost may be able to create both
short-term and long-term problems for all Bitcoin users. If the
created problems result in a rapid increase in user feerates, then
free relay attacks become cheaper due to low feerate transactions
being automatically evicted from the bottom of the mempool.

2. It may allow empting the mempool at relatively low cost. An attacke= r
sending just 750 transactions at the top mempool feerate can
guarantee eviction of every honest user's transactions. The at= tacker
can then replace 300 MB of transactions with a single 43,179 vbyte
transaction. Even if the replacement transaction pays 100
sats/vbyte, when you compare that to the 1,000,000 vbytes of
next-block transactions each miner lost, the miner is only earning = an
effective feerate of 4.3 sats/vbyte.

Further, it's easy to imagine situations where evicting
time-sensitive transactions from mempools might allow theft of fund= s
in excess of a few thousand dollars (my immediate thoughts go to
situations involving watchtowers).

3. Limiting the worst-case free relay and excessive mempool eviction
requires additional rules (e.g. one-shot RBFr) that are challenging
to implement and analyze at present, as several devs have noted[3].
Both implementation and analysis should become much easier if clust= er
mempool is deployed (also noted by devs), but the deployment of
cluster mempool requires removal of CPFP carve-out, and removal of
CPFP carve-out requires either the upgrade of thousands of LN nodes
and channels or a drop-in solution (ideally one that can be analyze= d
independently from cluster mempool, like TRUC).

To me, TRUC seems like an excellent approach. It's something that = can
be evaluated independently of cluster mempool but which can help allow
that deployment to proceed (in addition to the other previously
described benefits that TRUC brings).

There have already been multiple public discussions about how improved
RBF policies can be implemented once cluster mempool is available, many
of which bring us closer to something like RBFr in a way that's eas= ier
to prove won't enable free relay, and perusing that seems to me lik= e a
productive outlet if you are interested.

> this is quite an odd case of Core politics

I began writing this reply to force me to examine your claims for
myself. You have a long history of noticing things other people missed= .
I was worried that some compelling point of yours was being ignored as
the result of past controversies.

After several hours of writing and thinking, I don't see any proble= ms
with the current approach using TRUC or with the general lack of
interest in RBFr solutions at this time. I've tried to explain how= I
arrived at my conclusions at each step and I welcome any corrections.

Thanks,

-Dave

[1] https://delvingbitcoin.org/t/second-look-at-wea= k-blocks/805
[2]=20
https:/= /lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html<= /a>
[3]=20
https://bitcoinops.org/en/newsletters/2024= /02/07/#proposal-for-replace-by-feerate-to-escape-pinning

---
A simple free relay attack using RBFr

## Constants

100,000 vbytes =3D=3D ~400,000 bytes
A 1-input, 1-output P2TR scriptpath spend with the maximum amount
of witness data allowed by Bitcoin Core defaults

111 vbytes =3D=3D 162 bytes
A 1-input, 1-output P2TR keypath spend

## Attack

- Attacker obtains 500,000 UTXOs

- For each UTXO

- At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,00= 0
byte) transacton.

- Waits for it to propagate.

- At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacemen= t
that is 111 vbytes (162 bytes).

## Analysis

- At 162 bytes each, 500,000 transactions is 81 MB. I think that will
fit in a default-sized mempool.

- The total amount of transaction data relayed is 500_000 * (400_000 +
162), or about 200 GB.

- The typical daily bandwidth requirement of a blocks-only node is
roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
node is about the same due to compact blocks, but realistically, it&= #39;s
a small multiple of that. Call it 2 GB per day.

- This implies the attack push each RBFr relay node to use 100x a
non-RBFr relay node.

- At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
my nodes current mempoolminfee (1 sat/vb), that's 55.5 million s= ats,
or 0.55 BTC (about $37,000 USD).

- This analysis ignores the cost of obtaining the UTXOs and possibly
later consolidating them, but it also ignores some easy optimization= s
such as batching the replacements.

--
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/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com.=
------=_Part_507423_1098517225.1721527853625-- ------=_Part_507422_1310615009.1721527853625--