From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
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 ordinary
> BIP125 rules, and is thus "paying for" the bandwidth with a higher fe= e.
> Equally, in a replace-by-fee-rate scenario, it would be "payin= g for" its
> bandwidth with a higher fee-rate. Either way, somethin= g will confirm.

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

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

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

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

> Similar to what I w= rote above, in altruistic re-broadcasting, the attacker
> doing the= replacement cycling attack has already paid for the bandwidth
> co= nsumed in broadcasting the replaced transaction because they paid fees for<= br />> the cycling attack. Nothing more needs to be done beyond existing= RBF/RBFR
> rules to avoid DoS attacks.

And while I shar= e the opinon that for a classic altruistic re-broadcasting, an
attacke= r doing the replacement is paying for the bandwidth, this might be restrain= ed
by the caveat laid out above, namely exploiting the settlement timi= ng of a payment
channel network to drift the altruistic re-broadcastin= g behavior to a maximum of
concurrent propagation situation where the = bandwidth is wasted.

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

> I'm very curious as to what tho= se nodes are actually doing. Possibly some
> pre-made node distribu= tion is in fact setting non-standard mempool size limits.
> Or thes= e are fake spy nodes with unusual behavior.

I must say I have no= t investigated further myself in deep why some nodes sounds to
run wit= h lower mempool size, a likely explanation like you're pointing to is pre-m= ade
node running on raspi devices (with already other pre-configured s= ervices 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 tha= t is evicted, that is a
> straight-forward design flaw/bug in V3 tr= ansactions. Fixing that should be
> pretty straight forward, at whi= ch point the attacker is again paying "fairly"
> with fees on each = cycle.

This is correct that V3 transactions might still have ope= n design issues, w.r.t
parent package under mempool min transaction re= lay fees.

Best,
Antoine

Le mercredi 20 mars 2024 =C3=A0 2= 0:52:58 UTC, Peter Todd a =C3=A9crit=C2=A0:
(replying manually with a cut-n-paste due to= a mailing list delivery issue)

> > > > nodes should require higher minimum relay fees for = transactions close to
> > > their expiration height to ensure we don=E2=80=99t waste= bandwidth on transactions
> > > that have no potential to be mined
>=20
> I think this concern can be raised on _today_ LN second-stage tran= sactions (HTLC-preimage / HTLC-timeout),
> when a HTLC-preimage is broadcast near "cltv_expiry". LN= routing nodes will automatically go to broadcast an
> on-chain HTLC-timeout transaction. Probabilistically, we're wa= sting bandwidth on transactions that _might_ have
> lower odds to be mined.

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

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

> > If you already have a need to make such transactions, you can= argue that the
> > marginal cost to also use up that bandwidth is low. But that&= #39;s already the case
> > with RBF: we allow any transaction to be replaced with RBF fo= r a (by default)
> > 1sat/vB additional cost to "pay for" the bandwidth = of that replacement.
> > OP_EXPIRE does not change this situation: you're still pa= ying for an 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 i= ntroduced by OP_EXPIRE finality time-bounding semantics.
> However, I think it's more an issue if we introduce things lik= e altruistic re-broadcasting.
> =20
> ht= tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.= html
> =20
> Certainly, the re-broadcast could favor transactions with higher o= dds of being mined, which naively should match RBF rules.

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

> And by the same way taking time to answer the open questions on th= is thread from the old mailing list:
> ht= tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.= html
>=20
> > Are you claiming that BIP157 doesn't work well? In my exp= erience it does.
>=20
> I've not checked recently, though from research memory a while= back the numbers of BIP157 services offering peers
> was in the range of ~10 / 100.
>=20
> One can check by collecting nVersions messages from peers with `NO= DE_COMPACT_FILTERS`.

I mean, that's still BIP157 working. It's just not supported by= every node.
It's easy to learn about lots of addrs from the addr distribution m= echanisms,
so I don't think that's a serious issue.

> > 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 > 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% > 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
> > slope of the supply/demand curve is fairly flat right now.
>=20
> See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated f= rom diverging mempool min fees from the ground iirc.

https://github.com/bitcoi= n/bitcoin/issues/28371#issuecomment-1939604817 is the
only actual data I could find in that link.

I'm very curious as to what those nodes are actually doing. Possibl= y some
pre-made node distribution is in fact setting non-standard mempool size= 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 UTXO in a replacement cycling attack. The BIP125 rules, in particul= ar rule #4, ensure that each
> > replacement consumes liquidity because each replacement requi= res a higher fee, at least high enough to "pay for" the bandwidth= of the replacement. An attacker trying to > use the same UTXO'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= > to broadcast a transaction with a higher fee than some other transact= ion.
>=20
> This does not stay true with nVersion=3D3, where a package parent = can be signed with a feerate
> under min relay tx fee. See the second test attached in the initia= l full report email on replacement
> cycling attacks, one can replace the child of the package and the = parent 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 v= ictim 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 th= at
doesn't "pay for" the bandwidth of the parent that is evi= cted, that is a
straight-forward design flaw/bug in V3 transactions. Fixing that should= be
pretty straight forward, at which point the attacker is again paying &q= uot;fairly"
with fees on each cycle.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--
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/d9f8f4dc-e772-4383-8024-1e67695f5685n%40googlegroups.com.=
------=_Part_15926_1492412690.1718924947792-- ------=_Part_15925_912111495.1718924947792--