path: root/50/465916f1bb05fdcc319e68165c10b0e17239e2

Delivery-date: Sat, 16 Mar 2024 11:29:16 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRB46J26XQMGQEYMSMNCA@googlegroups.com>)
	id 1rlYmQ-0008Ud-V0
	for bitcoindev@gnusha.org; Sat, 16 Mar 2024 11:29:16 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-dd1395fd1bfsf5409742276.0
        for <bitcoindev@gnusha.org>; Sat, 16 Mar 2024 11:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1710613749; x=1711218549; 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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=;
        b=SH2+uiNunOXQmY6C49sDdkzS9yJ3nXEUF93OlLzukgwpxRLKgoQw5+HFKX3hSlrp+F
         ILHCHJNIffNXYIz484kwNBvBp/MEWQFtoOkCT7Xh8r4ZYM2nFJcRIRo2v9YFYFCzWVll
         K3yj1h0IdfznP1i7BekpZUzLQtTpMVFVEKtPJV/+r54+4wm5MnOn6ONZWIcC/Aq9Rpuq
         +sEctZmBc5jH55V7MDWLR+EfIySDc4Gtvdm7LVYAKDpJD/KuCNqDARKrp9HGrqxTIHrb
         oYsOsmyU4bVfDM4zP6Ko18vCav7ya/yh8hVtWh2sPKf7btUC66qPTKyD8UaBy0x42XYs
         cjWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1710613749; x=1711218549; 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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=;
        b=fQRbFnlOcykpyYDhOOax1//fI8lz2E0DisLNtVCH6olB4kj4Pfp6uiKyWg1/18FZWx
         7kiX77BerWEVVQ4dlU6q+5w8oT8of8yLW50PsTVs2ZH7tFGuU0EgHbT6l6oVAQPvEPAE
         gPEIYvv156BfOYb51aYrjPnRZBtPFUcPuQ9DwMmCCPed7Ibw22t9Nn2yaXNb6wUawZKy
         69/mHLyfO8gKpKThuy1T55ekITvId5mPUvAEBfAf+9Da6dvfWIjtWcGIoL8/23qgZWgt
         pYIOg9lTTDKP6tvenNoEKyHpqH4MFmHAGrUxtbhNFm0LU58yJpxTOcJliJrwm5mjHLAx
         i35A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710613749; x=1711218549;
        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=zEl9JRVUGgVq8o7bMM+Ep4FVEfYBM8nQFIYsxO4tmtk=;
        b=Xf7UMEQXGfX2nX56tjRpb/Gq2PR1bkFpZbJEgW1QZVNnRz16J0Y0M43bKFEQwUOzV+
         c61BzhgMZG3sRgzfrL0V61qXd+A1BwJwUnDBaL/5gWcGbbN5fTT1R50J1+j3fO2/Fq+l
         o0zee1C6u/5xmy0zWqCOwiM5Aoo1sHXe9vlFCo9NjLDDDnpTvuvNZT3XaEgX3EfBMG1f
         5yxJfySEmIdUVLTButXwZl3hJr0edhv4k1gbPh4I7+FscKTqMofcq6Olr/+1Ny7Crf1i
         WDBqpPCCdcbG09zL55CJOCHUcVAGTYuSuTNs6l4ZDc9razSn35L0L3hVMneZx7pzPeXx
         zPJg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWqNM+ktfXllIr2dUa4bYVbRtFqA137fbKAZX2K9neWIeRcreM008fFg4mxfKcszQX2OxJ0BTSUK2AueuLYT4s5PH7PMvI=
X-Gm-Message-State: AOJu0YzQ1P57pkVPl4DXvV+bGQZEi2xjnoTECQtFm+me1ty7ARO3+pY3
	sVD90DVYz7YKkaIOUepzkWFBm1PriqSc6F6pRKxFmHySqrev9MXK
X-Google-Smtp-Source: AGHT+IEZMlXva1nf+PUVu83k3OzZkK8Tiy1D+y5ZUThw8CtK7LK94ytRaIxmUuTAHTI5h5zQFIkpbQ==
X-Received: by 2002:a25:ab65:0:b0:dcf:afe3:11bf with SMTP id u92-20020a25ab65000000b00dcfafe311bfmr7714589ybi.0.1710613748399;
        Sat, 16 Mar 2024 11:29:08 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:b30d:0:b0:dcc:be89:34e3 with SMTP id l13-20020a25b30d000000b00dccbe8934e3ls960730ybj.1.-pod-prod-05-us;
 Sat, 16 Mar 2024 11:29:07 -0700 (PDT)
X-Received: by 2002:a05:6902:160e:b0:dcf:6b50:9bd7 with SMTP id bw14-20020a056902160e00b00dcf6b509bd7mr1691507ybb.7.1710613746925;
        Sat, 16 Mar 2024 11:29:06 -0700 (PDT)
Received: by 2002:a05:690c:387:b0:60a:5801:5e7b with SMTP id 00721157ae682-60a6aba0a29ms7b3;
        Sat, 16 Mar 2024 11:21:52 -0700 (PDT)
X-Received: by 2002:a05:6902:983:b0:dd9:1db5:8348 with SMTP id bv3-20020a056902098300b00dd91db58348mr35601ybb.8.1710613311219;
        Sat, 16 Mar 2024 11:21:51 -0700 (PDT)
Date: Sat, 16 Mar 2024 11:21:50 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <42adedc4-f3b0-4214-8f0d-2a27a3916fcen@googlegroups.com>
In-Reply-To: <ZfEeNcX3ebyuYYRi@petertodd.org>
References: <ZfEeNcX3ebyuYYRi@petertodd.org>
Subject: [bitcoindev] Re: OP_Expire mempool behavior
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_293258_1929047411.1710613310809"
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_293258_1929047411.1710613310809
Content-Type: multipart/alternative; 
	boundary="----=_Part_293259_1485164522.1710613310809"

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

> > > nodes should require higher minimum relay fees for transactions close=
=20
to
> > their expiration height to ensure we don=E2=80=99t waste bandwidth on=
=20
transactions
> > that have no potential to be mined

I think this concern can be raised on _today_ LN second-stage transactions=
=20
(HTLC-preimage / HTLC-timeout),
when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will=
=20
automatically go to broadcast an
on-chain HTLC-timeout transaction. Probabilistically, we're wasting=20
bandwidth on transactions that _might_ have
lower odds to be mined.

> If you already have a need to make such transactions, you can argue that=
=20
the
> marginal cost to also use up that bandwidth is low. But that's already=20
the case
> with RBF: we allow any transaction to be replaced with RBF for a (by=20
default)
> 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> OP_EXPIRE does not change this situation: you're still paying for an=20
additional
> 1sat/vB cost over the replaced transaction, as eventually one of your
> replacements will get mined.

I think yes this is indeed more a replacement issue, nothing new introduced=
=20
by OP_EXPIRE finality time-bounding semantics.
However, I think it's more an issue if we introduce things like altruistic=
=20
re-broadcasting.
=20
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02218=
8.html
=20
Certainly, the re-broadcast could favor transactions with higher odds of=20
being mined, which naively should match RBF rules.

And by the same way taking time to answer the open questions on this thread=
=20
from the old mailing list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02222=
4.html

> Are you claiming that BIP157 doesn't work well? In my experience it does.=
=20

I've not checked recently, though from research memory a while back the=20
numbers of BIP157 services offering peers
was in the range of ~10 / 100.

One can check by collecting nVersions messages from peers with=20
`NODE_COMPACT_FILTERS`.

> Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so=20
mempool min fees are very consistent across nodes. I just checked four=20
different long running > nodes I have access to, running a variety of=20
Bitcoin Core versions on different platforms and very different places in=
=20
the world, and their minfees all agree to well within 1%  > In fact, they=
=20
agree on min fee much *more* closely than the size of their mempools (in=20
terms of # of transactions). Which makes sense when you think about it, as=
=20
the
> slope of the supply/demand curve is fairly flat right now.

See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from=
=20
diverging mempool min fees from the ground iirc.

> From the point of view of a single node, an attacker can not reuse a UTXO=
=20
in a replacement cycling attack. The BIP125 rules, in particular rule #4,=
=20
ensure that each
> replacement consumes liquidity because each replacement requires a higher=
=20
fee, at least high enough to "pay for" the bandwidth of the replacement. An=
=20
attacker trying to > use the same UTXO's to cycle out multiple victim=20
transactions has to pay a higher fee for each victim cycled out. This is=20
because at each step of the cycle, the attacker had > to broadcast a=20
transaction with a higher fee than some other transaction.

This does not stay true with nVersion=3D3, where a package parent can be=20
signed with a feerate
under min relay tx fee. See the second test attached in the initial full=20
report email on replacement
cycling attacks, one can replace the child of the package and the parent is=
=20
automatically evicted,=20
without the "pay for" bandwidth of the replacement fully covered.

This is correct there is a minimal fee basis for each additional victim=20
cycled out, while one can get
a very advantageous scaling effect by RC'ing the child txn.

> If I understand correctly, here you are talking about an attacker with=20
connections to many different nodes at once, using the same UTXO(s) to do=
=20
replacement cycling
> attacks against different victim transactions on many different nodes at=
=20
once.

> There is no free lunch in this strategy. By using the same UTXO(s)=20
against multiple victims,
> the attacker dramatically reduces the effectiveness of the attack because=
=20
only a subset of nodes see each "side" of the attack.

The attacker assumptions is correct and relies on partitioning mempools.=20
However, I disagree
on the reduction in attack effectiveness as traditional LN nodes have only=
=20
one tx-relay edge access
to the tx-relay network (and LN nodes interfaces are a clusterfuck to do it=
=20
correctly here).

> Suppose that Mallory is connected directly or indirectly Alice and Bob's=
=20
nodes, and attempts to do a replacement cycling attack against both Alice=
=20
and Bob with the same
> UTXO(s).

> Both Alice and Bob's victim transactions spend different UTXOs, so every=
=20
node on the network can add both transactions to their mempool. When Alice=
=20
and Bob
>  broadcast their victim transactions, their nodes will tell multiple=20
peers about their respective transactions. Indeed, if alturistic=20
rebroadcasting is to be relevant at all, nodes > other than Alice and Bob's=
=20
*must* have learned about their transactions!

> Mallory on the other hand is creating divergent attack transactions that=
=20
are mututally
> incompatible. When Mallory broadcasts those attack transactions, from the=
=20
perspective of some nodes, Alice's victim transaction will be replaced out=
=20
but not Bob's, and
> from the perspective of other nodes, the opposite.

I'm assuming Mallory is partitioning Alice and Bob's local mempool from the=
=20
rest of the network
by using.2 distinct UTXOs. However their victim transactions won't=20
propagate out of their local
mempools due to Mallory's  higher / higher feerate conflicting=20
transactions. Mallory won't have to
paid the fan-out of 3.125 BTC of concurrent replacement, assuming the=20
partitioning isolation from
the rest of the network is well-done.

> Indeed, from the perspective of roughly half of the alturistic=20
rebroadcasting nodes, Alice's transaction was never cycled out, and the=20
other half, Bob's was never cycled out!

> Even in this case where the attack only used the same UTXO for two=20
targets, each victim transaction gets to roughly 50% of the mining nodes,=
=20
making the attack
> ineffective. And the numbers for Mallory just keep getting worse as he=20
targets more victims at once.

I think you can just use one UTXO for each RC target by broadcasting a=20
transaction in the target local
mempool's conflicting constantly with the malicious replacement transaction=
.

From my understanding, altruistic rebroadcasting only introduces the=20
encumbrance on the attacker to
add 1 UTXO per-victim's local mempool. I believe it's small advance to=20
mitigate replacement cycling attacks,
however a very cheap one given the marginal cost of a UTXO.

Best,
Antoine

Le mercredi 13 mars 2024 =C3=A0 05:10:40 UTC, Peter Todd a =C3=A9crit :

> I got a question re: the following comment on delvingbitcoin with regard =
to
> OP_Expire:
>
> > > nodes should require higher minimum relay fees for transactions close=
=20
> to
> > > their expiration height to ensure we don=E2=80=99t waste bandwidth on=
=20
> transactions
> > > that have no potential to be mined
> >
> > This seems insufficient to solve the problem, unless the premium is so=
=20
> high
> > that it virtually guarantees that the transaction will be mined before =
it
> > expires. However, if the feerate were that high, wouldn=E2=80=99t OP_EX=
PIRE=20
> simply
> > waste blockspace? If however the feerate of the transaction is merely
> > competitive, the presence of OP_EXPIRE creates a bandwidth-wasting=20
> vector: an
> > attacker would submit e.g. OP_EXPIRE transactions at the bottom of the=
=20
> top
> > block and push them out of the top block with further OP_EXPIRE=20
> transactions.
> > This way the attacker could issue a constant stream of transactions, bu=
t
> > never pay for more than a couple barely sliding in at the bottom of the
> > block.
> -https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8
>
> This "bandwidth-wasting vector" requires the attacker to create actual
> fee-paying transactions, with a fee-rate sufficiently high to get mined i=
n=20
> the
> next block or so. This of course is very expensive by itself.
>
> If you already have a need to make such transactions, you can argue that=
=20
> the
> marginal cost to also use up that bandwidth is low. But that's already th=
e=20
> case
> with RBF: we allow any transaction to be replaced with RBF for a (by=20
> default)
> 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> OP_EXPIRE does not change this situation: you're still paying for an=20
> additional
> 1sat/vB cost over the replaced transaction, as eventually one of your
> replacements will get mined.
>
> --=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/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com.

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

&gt; &gt; &gt; nodes should require higher minimum relay fees for transacti=
ons close to<br />&gt; &gt; their expiration height to ensure we don=E2=80=
=99t waste bandwidth on transactions<br />&gt; &gt; that have no potential =
to be mined<div><br /></div><div>I think this concern can be raised on _tod=
ay_ LN second-stage transactions (HTLC-preimage / HTLC-timeout),</div><div>=
when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will=
 automatically go to broadcast an</div><div>on-chain HTLC-timeout transacti=
on. Probabilistically, we're wasting bandwidth on transactions that _might_=
 have</div><div>lower odds to be mined.</div><div><br /></div><div>&gt; If =
you already have a need to make such transactions, you can argue that the<b=
r />&gt; marginal cost to also use up that bandwidth is low. But that's alr=
eady the case<br />&gt; with RBF: we allow any transaction to be replaced w=
ith RBF for a (by default)<br />&gt; 1sat/vB additional cost to "pay for" t=
he bandwidth of that replacement.<br />&gt; OP_EXPIRE does not change this =
situation: you're still paying for an additional<br />&gt; 1sat/vB cost ove=
r the replaced transaction, as eventually one of your<br />&gt; replacement=
s will get mined.<br /></div><div><br /></div><div>I think yes this is inde=
ed more a replacement issue, nothing new introduced by OP_EXPIRE finality t=
ime-bounding semantics.</div><div>However, I think it's more an issue if we=
 introduce things like altruistic re-broadcasting.</div><div>=C2=A0</div><d=
iv>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/02=
2188.html</div><div>=C2=A0</div><div>Certainly, the re-broadcast could favo=
r transactions with higher odds of being mined, which naively should match =
RBF rules.</div><div><br /></div><div>And by the same way taking time to an=
swer the open questions on this thread from the old mailing list:</div><div=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/0222=
24.html<br /></div><div><br /></div><div><span style=3D"caret-color: rgb(0,=
 0, 0); color: rgb(0, 0, 0);">&gt; Are you claiming that BIP157 doesn't wor=
k well? In my experience it does.
</span><br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" /><br =
/></div><div>I've not checked recently, though from research memory a while=
 back the numbers of BIP157 services offering peers</div><div>was in the ra=
nge of ~10 / 100.</div><div><br /></div><div>One can check by collecting nV=
ersions messages from peers with `NODE_COMPACT_FILTERS`.</div><div><br /></=
div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">&g=
t; Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so m=
empool
min fees are very consistent across nodes. I just checked four different lo=
ng
running &gt; nodes I have access to, running a variety of Bitcoin Core vers=
ions on
different platforms and very different places in the world, and their minfe=
es
all agree to well within 1% =C2=A0&gt; In fact, they agree on min fee much =
*more* closely than the size of their
mempools (in terms of # of transactions). Which makes sense when you think
about it, as the</span></div><div><span style=3D"caret-color: rgb(0, 0, 0);=
 color: rgb(0, 0, 0);">&gt; slope of the supply/demand curve is fairly flat=
 right now.</span><br /></div><div><br /></div><div>See https://github.com/=
bitcoin/bitcoin/pull/28488 which is motivated from diverging mempool min fe=
es from the ground iirc.</div><div><br /></div><div><span style=3D"caret-co=
lor: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; From the point of view of a s=
ingle node, an attacker can not reuse a UTXO in a
replacement cycling attack. The BIP125 rules, in particular rule #4, ensure
that each</span></div><div><span style=3D"caret-color: rgb(0, 0, 0); color:=
 rgb(0, 0, 0);">&gt; replacement consumes liquidity because each replacemen=
t requires a
higher fee, at least high enough to "pay for" the bandwidth of the replacem=
ent.

An attacker trying to &gt; use the same UTXO's to cycle out multiple victim
transactions has to pay a higher fee for each victim cycled out. This is
because at each step of the cycle, the attacker had &gt; to broadcast a tra=
nsaction
with a higher fee than some other transaction.</span><br /></div><div><br /=
></div><div>This does not stay true with nVersion=3D3, where a package pare=
nt can be signed with a feerate</div><div>under min relay tx fee. See the s=
econd test attached in the initial full report email on replacement</div><d=
iv>cycling attacks, one can replace the child of the package and the parent=
 is automatically evicted,=C2=A0</div><div>without the "pay for" bandwidth =
of the replacement fully covered.</div><div><br /></div><div>This is correc=
t there is a minimal fee basis for each additional victim cycled out, while=
 one can get</div><div>a very advantageous scaling effect by RC'ing the chi=
ld txn.</div><div><br /></div><div><span style=3D"caret-color: rgb(0, 0, 0)=
; color: rgb(0, 0, 0);">&gt; If I understand correctly, here you are talkin=
g about an attacker with
connections to many different nodes at once, using the same UTXO(s) to do
replacement cycling</span></div><div><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0);">&gt; attacks against different victim transaction=
s on many
different nodes at once.</span></div><div><span style=3D"caret-color: rgb(0=
, 0, 0); color: rgb(0, 0, 0);"><br /></span></div><div><span style=3D"caret=
-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; There is no free lunch in =
this strategy. By using the same UTXO(s) against
multiple victims,</span></div><div><span style=3D"caret-color: rgb(0, 0, 0)=
; color: rgb(0, 0, 0);">&gt; the attacker dramatically reduces the effectiv=
eness of the
attack because only a subset of nodes see each "side" of the attack.</span>=
</div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">=
<br /></span></div><div><font color=3D"#000000"><span style=3D"caret-color:=
 rgb(0, 0, 0);">The attacker assumptions is correct and relies on partition=
ing mempools. However, I disagree</span></font></div><div><font color=3D"#0=
00000"><span style=3D"caret-color: rgb(0, 0, 0);">on the reduction in attac=
k effectiveness as traditional LN nodes have only one tx-relay edge access<=
/span></font></div><div><font color=3D"#000000"><span style=3D"caret-color:=
 rgb(0, 0, 0);">to the tx-relay network (and LN nodes interfaces are a clus=
terfuck to do it correctly here).</span></font></div><div><br /></div><div>=
<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; Suppos=
e that Mallory is connected directly or indirectly Alice and Bob's nodes,
and attempts to do a replacement cycling attack against both Alice and Bob =
with
the same</span></div><div><span style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0);">&gt; UTXO(s).</span></div><div><span style=3D"caret-color: r=
gb(0, 0, 0); color: rgb(0, 0, 0);"><br /></span></div><div><span style=3D"c=
aret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; Both Alice and Bob's v=
ictim transactions spend different UTXOs, so every node
on the network can add both transactions to their mempool. When Alice and B=
ob</span></div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0,=
 0, 0);">&gt; =C2=A0broadcast their victim transactions, their nodes will t=
ell multiple peers about
their respective transactions. Indeed, if alturistic rebroadcasting is to b=
e
relevant at all, nodes &gt; other than Alice and Bob's *must* have learned =
about
their transactions!</span></div><div><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0);"><br /></span></div><div><span style=3D"caret-colo=
r: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; Mallory on the other hand is cr=
eating divergent attack transactions that are
mututally</span><br /></div><div><span style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0);">&gt; incompatible. When Mallory broadcasts those atta=
ck transactions, from
the perspective of some nodes, Alice's victim transaction will be replaced =
out
but not Bob's, and</span></div><div><span style=3D"caret-color: rgb(0, 0, 0=
); color: rgb(0, 0, 0);">&gt; from the perspective of other nodes, the oppo=
site.</span><font color=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0=
);"><br /></span></font></div><div><span style=3D"caret-color: rgb(0, 0, 0)=
; color: rgb(0, 0, 0);"><br /></span></div><div><font color=3D"#000000">I'm=
 assuming Mallory is partitioning Alice and Bob's local mempool from the re=
st of the network</font></div><div><font color=3D"#000000">by using.2 disti=
nct UTXOs. However their victim transactions won't propagate out of their l=
ocal</font></div><div><font color=3D"#000000">mempools due to Mallory's =C2=
=A0higher / higher feerate conflicting transactions. Mallory won't have to<=
/font></div><div><font color=3D"#000000">paid the fan-out of 3.125 BTC of c=
oncurrent replacement, assuming the partitioning isolation from</font></div=
><div><font color=3D"#000000">the rest of the network is well-done.</font><=
/div><div><font color=3D"#000000"><br /></font></div><div><span style=3D"ca=
ret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; Indeed, from the perspe=
ctive of roughly half of the alturistic rebroadcasting
nodes, Alice's transaction was never cycled out, and the other half, Bob's =
was
never cycled out!</span></div><div><span style=3D"caret-color: rgb(0, 0, 0)=
; color: rgb(0, 0, 0);"><br /></span></div><div><span style=3D"caret-color:=
 rgb(0, 0, 0); color: rgb(0, 0, 0);">&gt; Even in this case where the attac=
k only used the same UTXO for two targets,
each victim transaction gets to roughly 50% of the mining nodes, making the
attack</span></div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rg=
b(0, 0, 0);">&gt; ineffective. And the numbers for Mallory just keep gettin=
g worse as he
targets more victims at once.</span><font color=3D"#000000"><br /></font></=
div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><b=
r /></span></div><div><font color=3D"#000000"><span style=3D"caret-color: r=
gb(0, 0, 0);">I think you can just use one UTXO for each RC target by broad=
casting a transaction in the target local</span></font></div><div><font col=
or=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);">mempool's conflic=
ting constantly with the malicious replacement transaction.</span></font></=
div><div><font color=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);"=
><br /></span></font></div><div><font color=3D"#000000">From my understandi=
ng, altruistic rebroadcasting only introduces the encumbrance on the attack=
er to</font></div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb=
(0, 0, 0);">add 1 UTXO per-victim's local mempool. I believe it's small adv=
ance to mitigate replacement cycling attacks,</span></div><div><font color=
=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);">however a very chea=
p one given the marginal cost of a UTXO.</span></font></div><div><span styl=
e=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br /></span></div><d=
iv><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Best,</s=
pan></div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0=
);">Antoine</span></div><div><br /></div><div class=3D"gmail_quote"><div di=
r=3D"auto" class=3D"gmail_attr">Le mercredi 13 mars 2024 =C3=A0 05:10:40 UT=
C, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;">I got a question re: the following comment on delvingb=
itcoin with regard to
<br>OP_Expire:
<br>
<br>&gt; &gt; nodes should require higher minimum relay fees for transactio=
ns close to
<br>&gt; &gt; their expiration height to ensure we don=E2=80=99t waste band=
width on transactions
<br>&gt; &gt; that have no potential to be mined
<br>&gt;
<br>&gt; This seems insufficient to solve the problem, unless the premium i=
s so high
<br>&gt; that it virtually guarantees that the transaction will be mined be=
fore it
<br>&gt; expires. However, if the feerate were that high, wouldn=E2=80=99t =
OP_EXPIRE simply
<br>&gt; waste blockspace? If however the feerate of the transaction is mer=
ely
<br>&gt; competitive, the presence of OP_EXPIRE creates a bandwidth-wasting=
 vector: an
<br>&gt; attacker would submit e.g. OP_EXPIRE transactions at the bottom of=
 the top
<br>&gt; block and push them out of the top block with further OP_EXPIRE tr=
ansactions.
<br>&gt; This way the attacker could issue a constant stream of transaction=
s, but
<br>&gt; never pay for more than a couple barely sliding in at the bottom o=
f the
<br>&gt; block.
<br>-<a href=3D"https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t/op-checkmaxtimeverif=
y/581/8&amp;source=3Dgmail&amp;ust=3D1710694561157000&amp;usg=3DAOvVaw1lYLv=
1Uwpo5J_-pGWAP4lL">https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8=
</a>
<br>
<br>This &quot;bandwidth-wasting vector&quot; requires the attacker to crea=
te actual
<br>fee-paying transactions, with a fee-rate sufficiently high to get mined=
 in the
<br>next block or so. This of course is very expensive by itself.
<br>
<br>If you already have a need to make such transactions, you can argue tha=
t the
<br>marginal cost to also use up that bandwidth is low. But that&#39;s alre=
ady the case
<br>with RBF: we allow any transaction to be replaced with RBF for a (by de=
fault)
<br>1sat/vB additional cost to &quot;pay for&quot; the bandwidth of that re=
placement.
<br>OP_EXPIRE does not change this situation: you&#39;re still paying for a=
n additional
<br>1sat/vB cost over the replaced transaction, as eventually one of your
<br>replacements will get mined.
<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=3D1710694561157000&amp;usg=3DAOvVaw3=
99fGuVPL7Xl0o_-NsUrQT">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=3D1710694561157000&amp;usg=3DAOvVaw1-xvahAEA4h0=
joA_fbm5gF">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/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com</a>.=
<br />

------=_Part_293259_1485164522.1710613310809--

------=_Part_293258_1929047411.1710613310809--