path: root/da/6c6a4071410e73017debae11a3e9c2513f1e10

Delivery-date: Thu, 20 Jun 2024 16:58:14 -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 <bitcoindev+bncBC3PT7FYWAMRBDME2OZQMGQEK2HEK2I@googlegroups.com>)
	id 1sKRfR-0006G0-6a
	for bitcoindev@gnusha.org; Thu, 20 Jun 2024 16:58:14 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-dff2eb06c03sf433560276.1
        for <bitcoindev@gnusha.org>; Thu, 20 Jun 2024 16:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1718927887; x=1719532687; 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=s5CHNKTisLrG09Us2G/d9MVdCftS31h0UWWMRD/tlII=;
        b=pzqF875FhdPUTfR1IesmqxT0L+S9eVCd0WAmeJrHrQ07zVE0rYA0TMHTplDylL7t9F
         v/Kuleg7ns1756jzNdsHGVST3fQdgHb4t0gqishI5oyIsYxCtE2N44O1Nmlx3avGJf9k
         9Duz08+eXv/tAtvatZi/aCJ/0f6AJdOY30zX0+lnwatEPZ4C7uXXMLhQ2ZqHLtymLbpS
         dzv5SYaBNWA0dr1HVCUBUHDuStcjdR+FenxC7tIVSCvp0VmKZ6fMoBLGfN9AEPBeNL5E
         O58CixAkYJdbOLN5UaKqk0dc7FPIOOyBIqhTB0nqu0RwCOcUGZf+jVFZBaREO5In+vw3
         2AHg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1718927887; x=1719532687; 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=s5CHNKTisLrG09Us2G/d9MVdCftS31h0UWWMRD/tlII=;
        b=DHCpaM3KwKoqfvfmc1uMGO3/pU/t17qfqP7Wm9v404dfZK7sAN44AJ2a5CRR8w4RCd
         8JzH2e55T7Gce7l4aDnG9T/zD2czGohrz7bkd3xvfspec3LhOVeJwAhpBzko6osjTCHC
         fhyxyaUjwj7GINZoSPCsQ9TbmZNoLHDXemcKxFj4DnqWWMQzGPBtQ5WQNZ6vnjOTKpAJ
         8Wsz6j/tLumisDlUeKH+w5pSSSu6lKlStQWk2qWAHwcOW35dH0h2gzIHPiykU6iCliKq
         SQQA8VkHct8Y5OLMNk+/Cc+gtfou5hm/troGwR2B5cDA/TUeJbc5+MTBOC04Zeb/9TQP
         eUtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1718927887; x=1719532687;
        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=s5CHNKTisLrG09Us2G/d9MVdCftS31h0UWWMRD/tlII=;
        b=gKQlVqSNjoDZGAXBQT9+CZDHMKWRpQDbF1AIbq9D498pDrhrGLx9B8Gpuzvg3REhpz
         RIkh80fyWsgYEsjhLYHMoXXJ3FjoSEJc6JCnXCmSpRRxDfsJpI+LduDB3OVG326oH8Nu
         y6jeqMJuRRGltMavZwYdIjtmz51eM0XOuIX8D5HmyTsRMcB70Al2l8YMnRlR6nYUrXSH
         7XE6CyrL63P+lGdG9aEGFwINQeQb8igC3eeD08+lkwZlPvquKwyBI/0jPwfG90Xc65v3
         w7FF1OV0Bkgh1lfT7Kx5210Tem0mJzqhgZOjrWFJhgirgDyPhWe4rCWTxiBUN7tABkoy
         T0mQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUERQzTGHp5Y2Ch5Xjh24JF7j66qxucN+DRFwLCxnrOmQArD5yfoRyE76B4FwvoQc7UvZrC2HwW8q7fsYNpZ04pMNhCB2I=
X-Gm-Message-State: AOJu0Yw+qDdDItgEWkuQ0DZzncNcktp6n6083J/Z5B0bJ7DGiAkTHF5L
	JjsW+zSJ4cmH/4BoLMI9EeomRNnr2It89bMNYKEVNhVi9SelXSDB
X-Google-Smtp-Source: AGHT+IFowGm9ZEa7YRHsIyiuJ9S1N1RaykrvmLR4jsAWAwoJ/vL6sXMZiqOlN2T2g7seBj3fXCJktg==
X-Received: by 2002:a25:d041:0:b0:df7:8a41:3009 with SMTP id 3f1490d57ef6-e02be297ccamr6340086276.6.1718927886472;
        Thu, 20 Jun 2024 16:58:06 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:722:b0:dfd:ee2e:d48e with SMTP id
 3f1490d57ef6-e02d1003557ls1860710276.2.-pod-prod-05-us; Thu, 20 Jun 2024
 16:58:05 -0700 (PDT)
X-Received: by 2002:a05:6902:1106:b0:dfa:b2ca:7a9e with SMTP id 3f1490d57ef6-e02be2314ddmr1460779276.8.1718927885046;
        Thu, 20 Jun 2024 16:58:05 -0700 (PDT)
Received: by 2002:a81:8397:0:b0:627:7f59:2eee with SMTP id 00721157ae682-63a97a48f07ms7b3;
        Thu, 20 Jun 2024 16:09:09 -0700 (PDT)
X-Received: by 2002:a25:ab2c:0:b0:e02:d71e:87b5 with SMTP id 3f1490d57ef6-e02d71e8a5bmr222951276.6.1718924948026;
        Thu, 20 Jun 2024 16:09:08 -0700 (PDT)
Date: Thu, 20 Jun 2024 16:09:07 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d9f8f4dc-e772-4383-8024-1e67695f5685n@googlegroups.com>
In-Reply-To: <Zfmpi/9y4vFMAUtu@petertodd.org>
References: <ZfEeNcX3ebyuYYRi@petertodd.org>
 <Zfmpi/9y4vFMAUtu@petertodd.org>
Subject: [bitcoindev] Re: OP_Expire mempool behavior
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_15925_912111495.1718924947792"
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_15925_912111495.1718924947792
Content-Type: multipart/alternative; 
	boundary="----=_Part_15926_1492412690.1718924947792"

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

(pursuing the conversation as the problem of transaction with perishable=20
finality
in the mempool ain't solved)

> That's not really a comparable situation. If the HTLC-timeout transaction
> replaces a HTLC-preimage transaction in a mempool, it will do so under=20
ordinary
> BIP125 rules, and is thus "paying for" the bandwidth with a higher fee.
> Equally, in a replace-by-fee-rate scenario, it would be "paying for" its
> bandwidth with a higher fee-rate. Either way, something will confirm.

> In the OP_Expire case, we're talking about a transaction that becomes=20
entirely
> invalid after a point in time. If the transaction isn't mined with=20
reasonably
> high probability (eg >10%, preferably higher) an attacker may be able to
> consume bandwidth indefinitely at little to no cost.

In my view, there is a generic concept of "perishable transactions", i.e=20
transactions
of which the broadcast might be wasted by either a candidate replacement or=
=20
expiring
due to future semantics like op_expire.

This is correct that the latter is a bit different as there is no guarantee=
=20
that an on-chain
fee is paid (be it replace-by-fee or replace-by-fee-rate). However, from=20
the viewpoint of the
transaction-relay node there is still a probability that when the=20
HTLC-preimage broadcast time
is near `cltv_expiry`, the broadcast is "wasted" as it might be replaced=20
immediately by the
HTLC-timeout, even before it's fully propagated on the whole=20
transaction-relay topology.

I think you can reduce the observation in some LN configuration for an=20
attacker to waste
transaction-relay bandwidth, though there is a notable minimum bar, the=20
attacker might have
to bear channel on-chain funding cost.

> Similar to what I wrote above, in altruistic re-broadcasting, the attacke=
r
> doing the replacement cycling attack has already paid for the bandwidth
> consumed in broadcasting the replaced transaction because they paid fees=
=20
for
> the cycling attack. Nothing more needs to be done beyond existing RBF/RBF=
R
> rules to avoid DoS attacks.

And while I share the opinon that for a classic altruistic re-broadcasting,=
=20
an
attacker doing the replacement is paying for the bandwidth, this might be=
=20
restrained
by the caveat laid out above, namely exploiting the settlement timing of a=
=20
payment
channel network to drift the altruistic re-broadcasting behavior to a=20
maximum of
concurrent propagation situation where the bandwidth is wasted.

> I mean, that's still BIP157 working. It's just not supported by every=20
node.
> It's easy to learn about lots of addrs from the addr distribution=20
mechanisms,
> so I don't think that's a serious issue.
Yes, you can say it's still working though note how a limited number of=20
BIP157 peers
can open the doors to other risks, e.g privacy issues.=20

> I'm very curious as to what those nodes are actually doing. Possibly some
> pre-made node distribution is in fact setting non-standard mempool size=
=20
limits.
> Or these are fake spy nodes with unusual behavior.

I must say I have not investigated further myself in deep why some nodes=20
sounds to
run with lower mempool size, a likely explanation like you're pointing to=
=20
is pre-made
node running on raspi devices (with already other pre-configured services=
=20
running), where
mempool transaction buffering can be an issue.

> If V3 transactions is such that a child tx can be replaced at a cost that
> doesn't "pay for" the bandwidth of the parent that is evicted, that is a
> straight-forward design flaw/bug in V3 transactions. Fixing that should b=
e
> pretty straight forward, at which point the attacker is again paying=20
"fairly"
> with fees on each cycle.

This is correct that V3 transactions might still have open design issues,=
=20
w.r.t
parent package under mempool min transaction relay fees.

Best,
Antoine

Le mercredi 20 mars 2024 =C3=A0 20:52:58 UTC, Peter Todd a =C3=A9crit :

> (replying manually with a cut-n-paste due to a mailing list delivery issu=
e)
>
> > > > > nodes should require higher minimum relay fees for transactions=
=20
> close to
> > > > their expiration height to ensure we don=E2=80=99t waste bandwidth =
on=20
> transactions
> > > > that have no potential to be mined
> >=20
> > I think this concern can be raised on _today_ LN second-stage=20
> transactions (HTLC-preimage / HTLC-timeout),
> > when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes=
=20
> will 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.
>
> That's not really a comparable situation. If the HTLC-timeout transaction
> replaces a HTLC-preimage transaction in a mempool, it will do so under=20
> ordinary
> BIP125 rules, and is thus "paying for" the bandwidth with a higher fee.
> Equally, in a replace-by-fee-rate scenario, it would be "paying for" its
> bandwidth with a higher fee-rate. Either way, something will confirm.
>
> In the OP_Expire case, we're talking about a transaction that becomes=20
> entirely
> invalid after a point in time. If the transaction isn't mined with=20
> reasonably
> high probability (eg >10%, preferably higher) an attacker may be able to
> consume bandwidth indefinitely at little to no cost.
>
> > > If you already have a need to make such transactions, you can argue=
=20
> that the
> > > marginal cost to also use up that bandwidth is low. But that's alread=
y=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 replacemen=
t.
> > > 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
> > I think yes this is indeed more a replacement issue, nothing new=20
> introduced by OP_EXPIRE finality time-bounding semantics.
> > However, I think it's more an issue if we introduce things like=20
> altruistic re-broadcasting.
> >=20
> >=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
188.html
> >=20
> > Certainly, the re-broadcast could favor transactions with higher odds o=
f=20
> being mined, which naively should match RBF rules.
>
> Similar to what I wrote above, in altruistic re-broadcasting, the attacke=
r
> doing the replacement cycling attack has already paid for the bandwidth
> consumed in broadcasting the replaced transaction because they paid fees=
=20
> for
> the cycling attack. Nothing more needs to be done beyond existing RBF/RBF=
R
> rules to avoid DoS attacks.
>
> > And by the same way taking time to answer the open questions on this=20
> thread from the old mailing list:
> >=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
224.html
> >=20
> > > Are you claiming that BIP157 doesn't work well? In my experience it=
=20
> 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.
> >=20
> > One can check by collecting nVersions messages from peers with=20
> `NODE_COMPACT_FILTERS`.
>
> I mean, that's still BIP157 working. It's just not supported by every nod=
e.
> It's easy to learn about lots of addrs from the addr distribution=20
> mechanisms,
> so I don't think that's a serious issue.
>
> > > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, s=
o=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, a=
s=20
> the
> > > slope of the supply/demand curve is fairly flat right now.
> >=20
> > See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated=20
> from diverging mempool min fees from the ground iirc.
>
> https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817=
=20
> is the
> only actual data I could find in that link.
>
> I'm very curious as to what those nodes are actually doing. Possibly some
> pre-made node distribution is in fact setting non-standard mempool size=
=20
> limits.
> Or these are fake spy nodes with unusual behavior.
>
> > > From the point of view of a single node, an attacker can not reuse a=
=20
> UTXO in a replacement cycling attack. The BIP125 rules, in particular rul=
e=20
> #4, ensure that each
> > > replacement consumes liquidity because each replacement requires a=20
> higher fee, at least high enough to "pay for" the bandwidth of the=20
> replacement. An attacker trying to > use the same UTXO's to cycle out=20
> multiple victim transactions has to pay a higher fee for each victim cycl=
ed=20
> out. This is because at each step of the cycle, the attacker had > to=20
> broadcast a transaction with a higher fee than some other transaction.
> >=20
> > This does not stay true with nVersion=3D3, where a package parent can b=
e=20
> signed with a feerate
> > under min relay tx fee. See the second test attached in the initial ful=
l=20
> report email on replacement
> > cycling attacks, one can replace the child of the package and the paren=
t=20
> is automatically evicted,
> > without the "pay for" bandwidth of the replacement fully covered.
> >=20
> > 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 V3 transactions is such that a child tx can be replaced at a cost that
> doesn't "pay for" the bandwidth of the parent that is evicted, that is a
> straight-forward design flaw/bug in V3 transactions. Fixing that should b=
e
> pretty straight forward, at which point the attacker is again paying=20
> "fairly"
> with fees on each cycle.
>
> --=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/d9f8f4dc-e772-4383-8024-1e67695f5685n%40googlegroups.com.

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

(pursuing the conversation as the problem of transaction with perishable fi=
nality<br />in the mempool ain't solved)<br /><br />&gt; That's not really =
a comparable situation. If the HTLC-timeout transaction<br />&gt; replaces =
a HTLC-preimage transaction in a mempool, it will do so under ordinary<br /=
>&gt; BIP125 rules, and is thus "paying for" the bandwidth with a higher fe=
e.<br />&gt; Equally, in a replace-by-fee-rate scenario, it would be "payin=
g for" its<br />&gt; bandwidth with a higher fee-rate. Either way, somethin=
g will confirm.<br /><br />&gt; In the OP_Expire case, we're talking about =
a transaction that becomes entirely<br />&gt; invalid after a point in time=
. If the transaction isn't mined with reasonably<br />&gt; high probability=
 (eg &gt;10%, preferably higher) an attacker may be able to<br />&gt; consu=
me bandwidth indefinitely at little to no cost.<br /><br />In my view, ther=
e is a generic concept of "perishable transactions", i.e transactions<br />=
of which the broadcast might be wasted by either a candidate replacement or=
 expiring<br />due to future semantics like op_expire.<br /><br />This is c=
orrect that the latter is a bit different as there is no guarantee that an =
on-chain<br />fee is paid (be it replace-by-fee or replace-by-fee-rate). Ho=
wever, from the viewpoint of the<br />transaction-relay node there is still=
 a probability that when the HTLC-preimage broadcast time<br />is near `clt=
v_expiry`, the broadcast is "wasted" as it might be replaced immediately by=
 the<br />HTLC-timeout, even before it's fully propagated on the whole tran=
saction-relay topology.<br /><br />I think you can reduce the observation i=
n some LN configuration for an attacker to waste<br />transaction-relay ban=
dwidth, though there is a notable minimum bar, the attacker might have<br /=
>to bear channel on-chain funding cost.<br /><br />&gt; Similar to what I w=
rote above, in altruistic re-broadcasting, the attacker<br />&gt; doing the=
 replacement cycling attack has already paid for the bandwidth<br />&gt; co=
nsumed in broadcasting the replaced transaction because they paid fees for<=
br />&gt; the cycling attack. Nothing more needs to be done beyond existing=
 RBF/RBFR<br />&gt; rules to avoid DoS attacks.<br /><br />And while I shar=
e the opinon that for a classic altruistic re-broadcasting, an<br />attacke=
r doing the replacement is paying for the bandwidth, this might be restrain=
ed<br />by the caveat laid out above, namely exploiting the settlement timi=
ng of a payment<br />channel network to drift the altruistic re-broadcastin=
g behavior to a maximum of<br />concurrent propagation situation where the =
bandwidth is wasted.<br /><br />&gt; I mean, that's still BIP157 working. I=
t's just not supported by every node.<br />&gt; It's easy to learn about lo=
ts of addrs from the addr distribution mechanisms,<br />&gt; so I don't thi=
nk that's a serious issue.<br />Yes, you can say it's still working though =
note how a limited number of BIP157 peers<br />can open the doors to other =
risks, e.g privacy issues. <br /><br />&gt; I'm very curious as to what tho=
se nodes are actually doing. Possibly some<br />&gt; pre-made node distribu=
tion is in fact setting non-standard mempool size limits.<br />&gt; Or thes=
e are fake spy nodes with unusual behavior.<br /><br />I must say I have no=
t investigated further myself in deep why some nodes sounds to<br />run wit=
h lower mempool size, a likely explanation like you're pointing to is pre-m=
ade<br />node running on raspi devices (with already other pre-configured s=
ervices running), where<br />mempool transaction buffering can be an issue.=
<br /><br />&gt; If V3 transactions is such that a child tx can be replaced=
 at a cost that<br />&gt; doesn't "pay for" the bandwidth of the parent tha=
t is evicted, that is a<br />&gt; straight-forward design flaw/bug in V3 tr=
ansactions. Fixing that should be<br />&gt; pretty straight forward, at whi=
ch point the attacker is again paying "fairly"<br />&gt; with fees on each =
cycle.<br /><br />This is correct that V3 transactions might still have ope=
n design issues, w.r.t<br />parent package under mempool min transaction re=
lay fees.<br /><br />Best,<br />Antoine<br /><br /><div class=3D"gmail_quot=
e"><div dir=3D"auto" class=3D"gmail_attr">Le mercredi 20 mars 2024 =C3=A0 2=
0:52:58 UTC, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, =
204, 204); padding-left: 1ex;">(replying manually with a cut-n-paste due to=
 a mailing list delivery issue)
<br>
<br>&gt; &gt; &gt; &gt; nodes should require higher minimum relay fees for =
transactions close to
<br>&gt; &gt; &gt; their expiration height to ensure we don=E2=80=99t waste=
 bandwidth on transactions
<br>&gt; &gt; &gt; that have no potential to be mined
<br>&gt;=20
<br>&gt; I think this concern can be raised on _today_ LN second-stage tran=
sactions (HTLC-preimage / HTLC-timeout),
<br>&gt; when a HTLC-preimage is broadcast near &quot;cltv_expiry&quot;. LN=
 routing nodes will automatically go to broadcast an
<br>&gt; on-chain HTLC-timeout transaction. Probabilistically, we&#39;re wa=
sting bandwidth on transactions that _might_ have
<br>&gt; lower odds to be mined.
<br>
<br>That&#39;s not really a comparable situation. If the HTLC-timeout trans=
action
<br>replaces a HTLC-preimage transaction in a mempool, it will do so under =
ordinary
<br>BIP125 rules, and is thus &quot;paying for&quot; the bandwidth with a h=
igher fee.
<br>Equally, in a replace-by-fee-rate scenario, it would be &quot;paying fo=
r&quot; its
<br>bandwidth with a higher fee-rate. Either way, something will confirm.
<br>
<br>In the OP_Expire case, we&#39;re talking about a transaction that becom=
es entirely
<br>invalid after a point in time. If the transaction isn&#39;t mined with =
reasonably
<br>high probability (eg &gt;10%, preferably higher) an attacker may be abl=
e to
<br>consume bandwidth indefinitely at little to no cost.
<br>
<br>&gt; &gt; If you already have a need to make such transactions, you can=
 argue that the
<br>&gt; &gt; marginal cost to also use up that bandwidth is low. But that&=
#39;s already the case
<br>&gt; &gt; with RBF: we allow any transaction to be replaced with RBF fo=
r a (by default)
<br>&gt; &gt; 1sat/vB additional cost to &quot;pay for&quot; the bandwidth =
of that replacement.
<br>&gt; &gt; OP_EXPIRE does not change this situation: you&#39;re still pa=
ying for an additional
<br>&gt; &gt; 1sat/vB cost over the replaced transaction, as eventually one=
 of your
<br>&gt; &gt; replacements will get mined.
<br>&gt;=20
<br>&gt; I think yes this is indeed more a replacement issue, nothing new i=
ntroduced by OP_EXPIRE finality time-bounding semantics.
<br>&gt; However, I think it&#39;s more an issue if we introduce things lik=
e altruistic re-broadcasting.
<br>&gt; =20
<br>&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2023-December/022188.html" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-December/022188.html&amp;source=3D=
gmail&amp;ust=3D1719011255266000&amp;usg=3DAOvVaw21DTCknnQ6M475HpqMf2DD">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.=
html</a>
<br>&gt; =20
<br>&gt; Certainly, the re-broadcast could favor transactions with higher o=
dds of being mined, which naively should match RBF rules.
<br>
<br>Similar to what I wrote above, in altruistic re-broadcasting, the attac=
ker
<br>doing the replacement cycling attack has already paid for the bandwidth
<br>consumed in broadcasting the replaced transaction because they paid fee=
s for
<br>the cycling attack. Nothing more needs to be done beyond existing RBF/R=
BFR
<br>rules to avoid DoS attacks.
<br>
<br>&gt; And by the same way taking time to answer the open questions on th=
is thread from the old mailing list:
<br>&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2023-December/022224.html" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-December/022224.html&amp;source=3D=
gmail&amp;ust=3D1719011255266000&amp;usg=3DAOvVaw0RpcnTxwJm4lVumlGZXb9a">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.=
html</a>
<br>&gt;=20
<br>&gt; &gt; Are you claiming that BIP157 doesn&#39;t work well? In my exp=
erience it does.
<br>&gt;=20
<br>&gt; I&#39;ve not checked recently, though from research memory a while=
 back the numbers of BIP157 services offering peers
<br>&gt; was in the range of ~10 / 100.
<br>&gt;=20
<br>&gt; One can check by collecting nVersions messages from peers with `NO=
DE_COMPACT_FILTERS`.
<br>
<br>I mean, that&#39;s still BIP157 working. It&#39;s just not supported by=
 every node.
<br>It&#39;s easy to learn about lots of addrs from the addr distribution m=
echanisms,
<br>so I don&#39;t think that&#39;s a serious issue.
<br>
<br>&gt; &gt; Huh? Bitcoin nodes almost always use the same mempool limit, =
300MB, so mempool min fees are very consistent across nodes. I just checked=
 four different long running &gt; nodes I have access to, running a variety=
 of Bitcoin Core versions on different platforms and very different places =
in the world, and their minfees all agree to well within 1%  &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
<br>&gt; &gt; slope of the supply/demand curve is fairly flat right now.
<br>&gt;=20
<br>&gt; See <a href=3D"https://github.com/bitcoin/bitcoin/pull/28488" targ=
et=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.c=
om/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/28488&amp;so=
urce=3Dgmail&amp;ust=3D1719011255266000&amp;usg=3DAOvVaw15sZ7GmT9rUD6Y7G9Fv=
Wm9">https://github.com/bitcoin/bitcoin/pull/28488</a> which is motivated f=
rom diverging mempool min fees from the ground iirc.
<br>
<br><a href=3D"https://github.com/bitcoin/bitcoin/issues/28371#issuecomment=
-1939604817" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bitcoin/=
issues/28371%23issuecomment-1939604817&amp;source=3Dgmail&amp;ust=3D1719011=
255266000&amp;usg=3DAOvVaw2H8kEwr9trMyZ42T9a5Hv4">https://github.com/bitcoi=
n/bitcoin/issues/28371#issuecomment-1939604817</a> is the
<br>only actual data I could find in that link.
<br>
<br>I&#39;m very curious as to what those nodes are actually doing. Possibl=
y some
<br>pre-made node distribution is in fact setting non-standard mempool size=
 limits.
<br>Or these are fake spy nodes with unusual behavior.
<br>
<br>&gt; &gt; From the point of view of a single node, an attacker can not =
reuse a UTXO in a replacement cycling attack. The BIP125 rules, in particul=
ar rule #4, ensure that each
<br>&gt; &gt; replacement consumes liquidity because each replacement requi=
res a higher fee, at least high enough to &quot;pay for&quot; the bandwidth=
 of the replacement. An attacker trying to &gt; use the same UTXO&#39;s to =
cycle out multiple victim transactions has to pay a higher fee for each vic=
tim cycled out. This is because at each step of the cycle, the attacker had=
 &gt; to broadcast a transaction with a higher fee than some other transact=
ion.
<br>&gt;=20
<br>&gt; This does not stay true with nVersion=3D3, where a package parent =
can be signed with a feerate
<br>&gt; under min relay tx fee. See the second test attached in the initia=
l full report email on replacement
<br>&gt; cycling attacks, one can replace the child of the package and the =
parent is automatically evicted,
<br>&gt; without the &quot;pay for&quot; bandwidth of the replacement fully=
 covered.
<br>&gt;=20
<br>&gt; This is correct there is a minimal fee basis for each additional v=
ictim cycled out, while one can get
<br>&gt; a very advantageous scaling effect by RC&#39;ing the child txn.
<br>
<br>If V3 transactions is such that a child tx can be replaced at a cost th=
at
<br>doesn&#39;t &quot;pay for&quot; the bandwidth of the parent that is evi=
cted, that is a
<br>straight-forward design flaw/bug in V3 transactions. Fixing that should=
 be
<br>pretty straight forward, at which point the attacker is again paying &q=
uot;fairly&quot;
<br>with fees on each cycle.
<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=3D1719011255266000&amp;usg=3DAOvVaw2=
OsMTRmmYWceF2l1NcLmBr">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=3D1719011255266000&amp;usg=3DAOvVaw16DsSgkgtXpT=
owMSiYS-NW">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/d9f8f4dc-e772-4383-8024-1e67695f5685n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/d9f8f4dc-e772-4383-8024-1e67695f5685n%40googlegroups.com</a>.=
<br />

------=_Part_15926_1492412690.1718924947792--

------=_Part_15925_912111495.1718924947792--