path: root/cc/bdbac42769d818cd22ace5bfc253d4e85e0437

Delivery-date: Fri, 22 Mar 2024 16:24:07 -0700
Received: from mail-yw1-f184.google.com ([209.85.128.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBDVG7CXQMGQEEY3AWZI@googlegroups.com>)
	id 1rnoF4-0008LO-4X
	for bitcoindev@gnusha.org; Fri, 22 Mar 2024 16:24:07 -0700
Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-60a0a5bf550sf51493837b3.3
        for <bitcoindev@gnusha.org>; Fri, 22 Mar 2024 16:24:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1711149839; x=1711754639; 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=KWMtRPRCRsf5W7y4okufl1bcmMl6KM5zP4bqY03RjoQ=;
        b=tcSX+QBs5BttjM1Met0eCC6EVH5kn8ePRYXe/9lOzMonu37xNqwBVZlNY0hsXPaj/J
         H4ExAoj+c8fH/2Kd14yZkStTXsUsS8zH6aiQBxjqx+O1oxgRGo1C+Lv2tgZsR6RlALnc
         Fp0Axkis6gJAdlCkCXQQIbv/fvSJJ4Cl4AMPzcjKjupnXrkXLoleBdvUyGFQ9eTZj+6r
         42KkXKis5tG8MpRxEIHISFmqLu+qIUb+/ab3XwwAZVrooKTEw9Q5f5w2MQE7b4RLsfVd
         TeAQZLB7dd+uGjIvG3v/JgAsqP/3AFGNgzNKJ5MpXeVi8Mdy6cpD2AQqLiGJH2k/fZyD
         iH5Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711149839; x=1711754639; 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=KWMtRPRCRsf5W7y4okufl1bcmMl6KM5zP4bqY03RjoQ=;
        b=F13yWlWqcuwJ4Q2RiAqNHQ8y85dYOri/T5UmUAuuIdW1QwVtGQIOEUGiXD8nT5rsUg
         eTuDjsjgO/AeqQvi0dButdNuiSPTxIf0xSNTnUUKRHgJxM3glmYCWaUDcneKBtya6rFX
         gOj02ECwlCvCTCiZRZcvxRNYfcF1pvydOWUiuLSyGme+LINu8PL84tiz3U44U05lwzjP
         i0Sqe2CfGamcbNDK7kMIDoYy5axXGaTGpMcqniCxFMsg2Nh3fhti+5fboZETx8MMm/Bv
         yibWjdujWEbm8KNbMMNqNO5AeLWN528oKSj28yVIWhpaJVqAmJUubZ0lOdmKPmsGksll
         IQaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711149839; x=1711754639;
        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=KWMtRPRCRsf5W7y4okufl1bcmMl6KM5zP4bqY03RjoQ=;
        b=XAVQ0CHs3PB1J91+mHo4keq7pD5JTI+c4PTHi8Eh1OcmSUoIjDgz9tmoRKtCdcTP6y
         KTYpcNRpKVv35YEqQtozfSx5zvHQu66Ei2jCcVmAiP2J0JHc60iPyEfh73ZKua0na99+
         QlLamGgZWzn5UlJCB9gyczgApe1g3byxrJTqsNF1BZD6/xe6GjWMm6kiH9A/DDmNYDeP
         ktFycB20O/lKbeht9NdWP+2sFzUb5GbKyZclynj16n7zJj1Nl0rWnQx5e5ZvDk4rNAhZ
         RYO28r/7rDpI7d7WiKqxC5MWsXK/khDN9+vi/ptZyErrCXxC98LKapfDi/naP6dSonAW
         pxvA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXHxHMUMqPKIaD357hh3V+m5lwc7wDlLv5HWCled8vXUYXf6MFAekuRBbIyirQFcqUDL60UdSLeZ+MMi2fUsLys1AHmBYc=
X-Gm-Message-State: AOJu0Yy7pAkvOdvPhohvKo671+AR4v5p9iBHqnJ9K14yeWgLKF7q7g7W
	3iEWmQwOnIAnf3R3RP+WvDRYvnheidUyLBUCuMw39Dsyu60ir1Je
X-Google-Smtp-Source: AGHT+IF5i9P6NRDCwN2THugNAIrj9UWC0tl52ESwQBtA7l1VCvJjPJayLodwtAw2Y5P5uwexDtk4mQ==
X-Received: by 2002:a5b:b86:0:b0:dc6:b779:7887 with SMTP id l6-20020a5b0b86000000b00dc6b7797887mr779926ybq.20.1711149839490;
        Fri, 22 Mar 2024 16:23:59 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:e0c1:0:b0:dcc:37ed:efb1 with SMTP id x184-20020a25e0c1000000b00dcc37edefb1ls614738ybg.2.-pod-prod-00-us;
 Fri, 22 Mar 2024 16:23:58 -0700 (PDT)
X-Received: by 2002:a81:ad10:0:b0:611:336c:2b88 with SMTP id l16-20020a81ad10000000b00611336c2b88mr107166ywh.0.1711149838087;
        Fri, 22 Mar 2024 16:23:58 -0700 (PDT)
Received: by 2002:a05:690c:113:b0:611:2a20:d0cc with SMTP id 00721157ae682-6112a20d53fms7b3;
        Fri, 22 Mar 2024 16:18:19 -0700 (PDT)
X-Received: by 2002:a05:6902:2012:b0:dc6:207e:e8b1 with SMTP id dh18-20020a056902201200b00dc6207ee8b1mr263457ybb.2.1711149498616;
        Fri, 22 Mar 2024 16:18:18 -0700 (PDT)
Date: Fri, 22 Mar 2024 16:18:18 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
In-Reply-To: <Zfg/6IZyA/iInyMx@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
Subject: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_186140_1813415044.1711149498179"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_186140_1813415044.1711149498179
Content-Type: multipart/alternative; 
	boundary="----=_Part_186141_412490975.1711149498179"

------=_Part_186141_412490975.1711149498179
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> The marginal cost to an attacker who was planning on broadcasting B=20
anyway is=20
> fairly small, as provided that sufficiently small fee-rates are chosen=20
for A_n,=20
> the probability of A_n being mined is low. The attack does of course=20
require=20
> capital, as the attacker needs to have UTXO's of sufficient size for A_n.

I think an attacker does not necessarily need to have a UTXO's of=20
sufficient size for A_n.
One could reuse feerate ascending old LN states, where the balance on=20
latest states is
in favor of your counterparty. So it might be a lower assumption on=20
attacker ressources,
you only needs to have been _allocate_ a shared-UTXO in the past.

> The larger the mempool size limit, the more=20
> effective the attack tends to be. Similarly, the attack is more effective=
=20
with=20
> a larger size difference between A and B. Finally, the attack is more=20
effective=20
> with a smaller minimum incremental relay fee, as more individual versions=
=20
of=20
> the transaction can be broadcast for a given fee-delta range.

I think the observation on larger the mempool size, more effective the=20
attack tends
to come as a novel insight to me. Naively, in a world where the future=20
blockspace
demand is uncertain, miners have an incentive to scale up their mempool=20
size limit.
As such, holding a cache of non-mined low-feerates transactions. The type=
=20
of bandwidth,
denial-of-service described sounds effectively to affect more full-nodes=20
with large=20
mempools. Fair point, it's expected they have more bandwidth ressources=20
available too.

> Of course, this attack can be parallelized, with many non-conflicting A_n=
=20
> chains at once. Depending on P2P topology, maximum bandwidth may be=20
consumable=20
> by broadcasting multiple _conflicting_ A's to different nodes at once=C2=
=B2, a=20
> fairly obvious attack that I (and probably others) have already disclosed=
.

Yes, if I remember correctly bandwidth wasting attacks by exploiting RBF=20
propagation
asymmetries were considered in 2021 when an automatic mempool=20
rebroadcasting implementation
was proposed in Bitcoin Core. And alternatively, I echoed mempool=20
partitioning concerns
during the tx-relay workshops on IRC in the same year of 2021, notably how=
=20
you can use
to increase pinning attacks odds of success (assuming time-sensitive nodes=
=20
e.g LN have
a single local mempool).

Commenting on this, do we have a free-relay attack variant where an=20
attacker with reasonable
visibility on the transaction-relay network could exploit propagation=20
asymmetries due to
*_INVENTORY_BROADCAST_INTERVAL and re-inject A_n traffic in a targeted=20
fashion ?
I don't think it's worst than the parallelization you're describing, it's=
=20
just another approach.

> Requiring replacements to increase the fee-rate by a certain ratio would=
=20
also=20
> mitigate the attack. However doing so would break a lot of wallet=20
software that=20
> bumps fees by values equal or close to the minimum relay fee.

I think there is still the open questions of the economic relevance of=20
replace-by-fee if
the local mempool is completely empty. Here a miner is optimizing to=20
maximize absolute
fee as a transaction replaced by a higher-feerate, lower fee is less=20
interesting if you have
less than 1 MB virtual bytes / 4 MB WU.

> Ironically, the existence of this attack is an argument in favor of=20
> replace-by-fee-rate. While RBFR introduces a degree of free-relay, the=20
fact=20
> that Bitcoin Core's existing rules *also* allow for free-relay in this=20
form=20
> makes the difference inconsequential.

Back on the point where an attacker ability to provoke bandwidth DoS in=20
considerations
of the UTXO-amount available, a minimal absolute fee as a proof of owning=
=20
some UTXO
amount could be still maintained (or maybe after a _bounded_ number of=20
replacement under
a given block period).

We studied proof-of-UTXO ownership as a p2p DoS mitigation approach in the=
=20
past with Gleb:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002=
884.html

Best,
Antoine


Le lundi 18 mars 2024 =C3=A0 13:24:12 UTC, Peter Todd a =C3=A9crit :

> RBF Rule #6 requires that a replacement transaction have a fee-rate highe=
r=20
> than
> the fee-rate of all conflicting transactions. This rule aligns economic
> incentives, as in most circumstances miners earn more money by mining a=
=20
> higher
> fee-rate transaction than a lower fee-rate transaction, even if the=20
> absolute
> fee paid by the replacement is more.
>
> While RBF Rule #6 was implemented as part of my original Full-RBF opt-in
> pull-req=C2=B9, it was mistakenly left out of BIP-125, which was written =
later=20
> by
> Harding. Thus it's often forgotten in analysis of RBF.
>
> Rule #6 creates a path dependency: the order in which replacement=20
> transactions
> are received determines which transactions are ultimately accepted. This
> creates an opportunity for free-relay, as follows:
>
> 1. Create two transactions, A and B, where A is a large, low fee-rate, hi=
gh
> absolute fee, transaction, and B is a small, high fee-rate, low absolute=
=20
> fee
> transaction.
>
> 2. Broadcast A and B to different nodes simultaneously.
>
> 3. Nodes that receive A first will not replace A with B, because B pays a=
=20
> lower
> fee, violating RBF Rule #3. Notes that receive B first, will not replace =
B=20
> with
> A, because A has a lower fee-rate, violating RBF Rule #6.
>
> 4. Create A_1, a transaction with the same (large) size as A, but paying =
a
> slightly higher fee (and thus fee-rate). Nodes that received A first will
> replace A with A_1, consuming bandwidth. These nodes will also broadcast=
=20
> A_1 to
> peers who have B, consuming their bandwidth even though they reject A_1.
>
> 5. Repeat until A_n has a fee-rate high enough to have a non-trivial risk=
=20
> of
> being mined. Or B is mined, invalidating all A_n.
>
> The marginal cost to an attacker who was planning on broadcasting B anywa=
y=20
> is
> fairly small, as provided that sufficiently small fee-rates are chosen fo=
r=20
> A_n,
> the probability of A_n being mined is low. The attack does of course=20
> require
> capital, as the attacker needs to have UTXO's of sufficient size for A_n.
>
> The attack is most effective in cases where fee-rates have a significant=
=20
> slope
> to them, with the minimum relay fee being small compared to the=20
> competitive fee
> to get into the next block. The larger the mempool size limit, the more
> effective the attack tends to be. Similarly, the attack is more effective=
=20
> with
> a larger size difference between A and B. Finally, the attack is more=20
> effective
> with a smaller minimum incremental relay fee, as more individual versions=
=20
> of
> the transaction can be broadcast for a given fee-delta range.
>
> Of course, this attack can be parallelized, with many non-conflicting A_n
> chains at once. Depending on P2P topology, maximum bandwidth may be=20
> consumable
> by broadcasting multiple _conflicting_ A's to different nodes at once=C2=
=B2, a
> fairly obvious attack that I (and probably others) have already disclosed=
.
>
>
> # Mitigations
>
> Replace-by-Fee-Rate mitigates the attack, by limiting the possible range =
of
> fee-rate delta. For example, in Libre Relay, which does=20
> replace-by-fee-rate at
> a fee-rate ratio of >=3D 2x, if A starts at 3sat/VB, the attacker can onl=
y=20
> do 2
> cycles of the attack as a B >=3D 6sat/VB will simply replace A.
>
> The attack itself is arguably an economic exploit: *because* Bitcoin Core
> doesn't yet implement replace-by-fee-rate, nodes who accepted A first, ar=
e
> wasting their bandwidth relaying variations on A that are clearly less
> desirable to miners than B. An economically rational miner would just min=
e=20
> B
> right now, and the fact that _other_ economically rational miners would=
=20
> mine B
> just strengthens the case for mining B now. Indeed, real-world=20
> measurements of
> replace-by-fee-rate have found that (most likely) due to mempool
> inconsistencies, roughly half or more=C2=B3 of RBFR replacements are mine=
d=20
> already.
>
> Requiring replacements to increase the fee-rate by a certain ratio would=
=20
> also
> mitigate the attack. However doing so would break a lot of wallet softwar=
e=20
> that
> bumps fees by values equal or close to the minimum relay fee.
>
>
> # Related Attacks
>
> Rule #6 is just one of many ways to achieve the same effect: getting a=20
> miner to
> invalidate a set of large transactions, wasting bandwidth. For example,=
=20
> miners
> who accept payment for guaranteeing that a specific transaction gets mine=
d=20
> also
> make this kind of attack possible.
>
>
> # Discussion
>
> Ironically, the existence of this attack is an argument in favor of
> replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fa=
ct
> that Bitcoin Core's existing rules *also* allow for free-relay in this fo=
rm
> makes the difference inconsequential.
>
>
> # Disclosure
>
> This issue was disclosed to bitcoin-security first. I received no=20
> objections to
> making it public. All free-relay attacks are mitigated by the requirement=
=20
> to at
> least have sufficient funds available to allocate to fees, even if the=20
> funds
> might not actually be spent.
>
>
> # References
>
> 1) https://github.com/bitcoin/bitcoin/pull/6871
> 2) https://petertodd.org/2024/one-shot-replace-by-fee-rate#the-status-quo
> 3) https://petertodd.org/2024/replace-by-fee-rate-success-rate
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/0a377ddb-b001-41ba-9208-27b3fa059bb5n%40googlegroups.com.

------=_Part_186141_412490975.1711149498179
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<div><br /></div><div>&gt; The marginal cost to an attacker who wa=
s planning on broadcasting B anyway is=C2=A0<br />&gt; fairly small, as pro=
vided that sufficiently small fee-rates are chosen for A_n,=C2=A0<br />&gt;=
 the probability of A_n being mined is low. The attack does of course requi=
re=C2=A0<br />&gt; capital, as the attacker needs to have UTXO's of suffici=
ent size for A_n.</div><div><br /></div><div>I think an attacker does not n=
ecessarily need to have a UTXO's of sufficient size for A_n.</div><div>One =
could reuse feerate ascending old LN states, where the balance on latest st=
ates is</div><div>in favor of your counterparty. So it might be a lower ass=
umption on attacker ressources,</div><div>you only needs to have been _allo=
cate_ a shared-UTXO in the past.</div><div><br /></div><div>&gt; The larger=
 the mempool size limit, the more=C2=A0<br />&gt; effective the attack tend=
s to be. Similarly, the attack is more effective with=C2=A0<br />&gt; a lar=
ger size difference between A and B. Finally, the attack is more effective=
=C2=A0<br />&gt; with a smaller minimum incremental relay fee, as more indi=
vidual versions of=C2=A0<br />&gt; the transaction can be broadcast for a g=
iven fee-delta range.</div><div><br /></div><div>I think the observation on=
 larger the mempool size, more effective the attack tends</div><div>to come=
 as a novel insight to me. Naively, in a world where the future blockspace<=
/div><div>demand is uncertain, miners have an incentive to scale up their m=
empool size limit.</div><div>As such, holding a cache of non-mined low-feer=
ates transactions. The type of bandwidth,</div><div>denial-of-service descr=
ibed sounds effectively to affect more full-nodes with large=C2=A0</div><di=
v>mempools. Fair point, it's expected they have more bandwidth ressources a=
vailable too.</div><div><br /></div><div>&gt; Of course, this attack can be=
 parallelized, with many non-conflicting A_n=C2=A0<br />&gt; chains at once=
. Depending on P2P topology, maximum bandwidth may be consumable=C2=A0<br /=
>&gt; by broadcasting multiple _conflicting_ A's to different nodes at once=
=C2=B2, a=C2=A0<br />&gt; fairly obvious attack that I (and probably others=
) have already disclosed.</div><div><br /></div><div>Yes, if I remember cor=
rectly bandwidth wasting attacks by exploiting RBF propagation</div><div>as=
ymmetries were considered in 2021 when an automatic mempool rebroadcasting =
implementation</div><div>was proposed in Bitcoin Core. And alternatively, I=
 echoed mempool partitioning concerns</div><div>during the tx-relay worksho=
ps on IRC in the same year of 2021, notably how you can use</div><div>to in=
crease pinning attacks odds of success (assuming time-sensitive nodes e.g L=
N have</div><div>a single local mempool).</div><div><br /></div><div>Commen=
ting on this, do we have a free-relay attack variant where an attacker with=
 reasonable</div><div>visibility on the transaction-relay network could exp=
loit propagation asymmetries due to</div><div>*_INVENTORY_BROADCAST_INTERVA=
L and re-inject A_n traffic in a targeted fashion ?</div><div>I don't think=
 it's worst than the parallelization you're describing, it's just another a=
pproach.</div><div><br /></div><div>&gt; Requiring replacements to increase=
 the fee-rate by a certain ratio would also=C2=A0<br />&gt; mitigate the at=
tack. However doing so would break a lot of wallet software that=C2=A0<br /=
>&gt; bumps fees by values equal or close to the minimum relay fee.<br /></=
div><div><br /></div><div>I think there is still the open questions of the =
economic relevance of replace-by-fee if</div><div>the local mempool is comp=
letely empty. Here a miner is optimizing to maximize absolute</div><div>fee=
 as a transaction replaced by a higher-feerate, lower fee is less interesti=
ng if you have</div><div>less than 1 MB virtual bytes / 4 MB WU.</div><div>=
<br /></div><div>&gt; Ironically, the existence of this attack is an argume=
nt in favor of=C2=A0<br />&gt; replace-by-fee-rate. While RBFR introduces a=
 degree of free-relay, the fact=C2=A0<br />&gt; that Bitcoin Core's existin=
g rules *also* allow for free-relay in this form=C2=A0<br />&gt; makes the =
difference inconsequential.<br /></div><div><br /></div><div>Back on the po=
int where an attacker ability to provoke bandwidth DoS in considerations</d=
iv><div>of the UTXO-amount available, a minimal absolute fee as a proof of =
owning some UTXO</div><div>amount could be still maintained (or maybe after=
 a _bounded_ number of replacement under</div><div>a given block period).</=
div><div><br /></div><div>We studied proof-of-UTXO ownership as a p2p DoS m=
itigation approach in the past with Gleb:</div><div>https://lists.linuxfoun=
dation.org/pipermail/lightning-dev/2020-November/002884.html<br /></div><di=
v><br /></div><div>Best,</div><div>Antoine</div><div><br /><br /></div><div=
 class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le lundi 18 m=
ars 2024 =C3=A0 13:24:12 UTC, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">RBF Rule #6 requires that a=
 replacement transaction have a fee-rate higher than
<br>the fee-rate of all conflicting transactions. This rule aligns economic
<br>incentives, as in most circumstances miners earn more money by mining a=
 higher
<br>fee-rate transaction than a lower fee-rate transaction, even if the abs=
olute
<br>fee paid by the replacement is more.
<br>
<br>While RBF Rule #6 was implemented as part of my original Full-RBF opt-i=
n
<br>pull-req=C2=B9, it was mistakenly left out of BIP-125, which was writte=
n later by
<br>Harding. Thus it&#39;s often forgotten in analysis of RBF.
<br>
<br>Rule #6 creates a path dependency: the order in which replacement trans=
actions
<br>are received determines which transactions are ultimately accepted. Thi=
s
<br>creates an opportunity for free-relay, as follows:
<br>
<br>1. Create two transactions, A and B, where A is a large, low fee-rate, =
high
<br>   absolute fee, transaction, and B is a small, high fee-rate, low abso=
lute fee
<br>   transaction.
<br>
<br>2. Broadcast A and B to different nodes simultaneously.
<br>
<br>3. Nodes that receive A first will not replace A with B, because B pays=
 a lower
<br>   fee, violating RBF Rule #3. Notes that receive B first, will not rep=
lace B with
<br>   A, because A has a lower fee-rate, violating RBF Rule #6.
<br>
<br>4. Create A_1, a transaction with the same (large) size as A, but payin=
g a
<br>   slightly higher fee (and thus fee-rate). Nodes that received A first=
 will
<br>   replace A with A_1, consuming bandwidth. These nodes will also broad=
cast A_1 to
<br>   peers who have B, consuming their bandwidth even though they reject =
A_1.
<br>
<br>5. Repeat until A_n has a fee-rate high enough to have a non-trivial ri=
sk of
<br>   being mined. Or B is mined, invalidating all A_n.
<br>
<br>The marginal cost to an attacker who was planning on broadcasting B any=
way is
<br>fairly small, as provided that sufficiently small fee-rates are chosen =
for A_n,
<br>the probability of A_n being mined is low. The attack does of course re=
quire
<br>capital, as the attacker needs to have UTXO&#39;s of sufficient size fo=
r A_n.
<br>
<br>The attack is most effective in cases where fee-rates have a significan=
t slope
<br>to them, with the minimum relay fee being small compared to the competi=
tive fee
<br>to get into the next block. The larger the mempool size limit, the more
<br>effective the attack tends to be. Similarly, the attack is more effecti=
ve with
<br>a larger size difference between A and B. Finally, the attack is more e=
ffective
<br>with a smaller minimum incremental relay fee, as more individual versio=
ns of
<br>the transaction can be broadcast for a given fee-delta range.
<br>
<br>Of course, this attack can be parallelized, with many non-conflicting A=
_n
<br>chains at once.  Depending on P2P topology, maximum bandwidth may be co=
nsumable
<br>by broadcasting multiple _conflicting_ A&#39;s to different nodes at on=
ce=C2=B2,	a
<br>fairly obvious attack that I (and probably others) have already disclos=
ed.
<br>
<br>
<br># Mitigations
<br>
<br>Replace-by-Fee-Rate mitigates the attack, by limiting the possible rang=
e of
<br>fee-rate delta. For example, in Libre Relay, which does replace-by-fee-=
rate at
<br>a fee-rate ratio of &gt;=3D 2x, if A starts at 3sat/VB, the attacker ca=
n only do 2
<br>cycles of the attack as a B &gt;=3D 6sat/VB will simply replace A.
<br>
<br>The attack itself is arguably an economic exploit: *because* Bitcoin Co=
re
<br>doesn&#39;t yet implement replace-by-fee-rate, nodes who accepted A fir=
st, are
<br>wasting their bandwidth relaying variations on A that are clearly less
<br>desirable to miners than B. An economically rational miner would just m=
ine B
<br>right now, and the fact that _other_ economically rational miners would=
 mine B
<br>just strengthens the case for mining B now. Indeed, real-world measurem=
ents of
<br>replace-by-fee-rate have found that (most likely) due to mempool
<br>inconsistencies, roughly half or more=C2=B3 of RBFR replacements are mi=
ned already.
<br>
<br>Requiring replacements to increase the fee-rate by a certain ratio woul=
d also
<br>mitigate the attack. However doing so would break a lot of wallet softw=
are that
<br>bumps fees by values equal or close to the minimum relay fee.
<br>
<br>
<br># Related Attacks
<br>
<br>Rule #6 is just one of many ways to achieve the same effect: getting a =
miner to
<br>invalidate a set of large transactions, wasting bandwidth. For example,=
 miners
<br>who accept payment for guaranteeing that a specific transaction gets mi=
ned also
<br>make this kind of attack possible.
<br>
<br>
<br># Discussion
<br>
<br>Ironically, the existence of this attack is an argument in favor of
<br>replace-by-fee-rate. While RBFR introduces a degree of free-relay, the =
fact
<br>that Bitcoin Core&#39;s existing rules *also* allow for free-relay in t=
his form
<br>makes the difference inconsequential.
<br>
<br>
<br># Disclosure
<br>
<br>This issue was disclosed to bitcoin-security first. I received no objec=
tions to
<br>making it public. All free-relay attacks are mitigated by the requireme=
nt to at
<br>least have sufficient funds available to allocate to fees, even if the =
funds
<br>might not actually be spent.
<br>
<br>
<br># References
<br>
<br>1) <a href=3D"https://github.com/bitcoin/bitcoin/pull/6871" target=3D"_=
blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/6871&amp;source=3Dg=
mail&amp;ust=3D1711235008407000&amp;usg=3DAOvVaw11MTBjY2rxf_4PCj9xSX7r">htt=
ps://github.com/bitcoin/bitcoin/pull/6871</a>
<br>2) <a href=3D"https://petertodd.org/2024/one-shot-replace-by-fee-rate#t=
he-status-quo" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://petertodd.org/2024/one-sh=
ot-replace-by-fee-rate%23the-status-quo&amp;source=3Dgmail&amp;ust=3D171123=
5008407000&amp;usg=3DAOvVaw1Nsi4kIUmYdvPbw7uc_M0a">https://petertodd.org/20=
24/one-shot-replace-by-fee-rate#the-status-quo</a>
<br>3) <a href=3D"https://petertodd.org/2024/replace-by-fee-rate-success-ra=
te" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.=
google.com/url?hl=3Dfr&amp;q=3Dhttps://petertodd.org/2024/replace-by-fee-ra=
te-success-rate&amp;source=3Dgmail&amp;ust=3D1711235008407000&amp;usg=3DAOv=
Vaw054cnXXUk0YENNgd9i22iA">https://petertodd.org/2024/replace-by-fee-rate-s=
uccess-rate</a>
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1711235008407000&amp;usg=3DAOvVaw0=
EbeiFNf5TxqgZXrBhazXh">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1711235008407000&amp;usg=3DAOvVaw35-XwJUMS2V_=
GTFNhsO_3z">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/0a377ddb-b001-41ba-9208-27b3fa059bb5n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/0a377ddb-b001-41ba-9208-27b3fa059bb5n%40googlegroups.com</a>.=
<br />

------=_Part_186141_412490975.1711149498179--

------=_Part_186140_1813415044.1711149498179--