Delivery-date: Wed, 20 Mar 2024 13:53:05 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158;
Feedback-ID: i525146e8:Fastmail
Date: Tue, 19 Mar 2024 15:04:43 +0000
From: Peter Todd <pete@petertodd.org>
To: antoine.riard@gmail.com
Cc: bitcoindev@googlegroups.com
Subject: [bitcoindev] Re: OP_Expire mempool behavior
Message-ID: <Zfmpi/9y4vFMAUtu@petertodd.org>
References: <ZfEeNcX3ebyuYYRi@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="sffbIHzw3cDuBla2"
Content-Disposition: inline
In-Reply-To: <ZfEeNcX3ebyuYYRi@petertodd.org>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--sffbIHzw3cDuBla2
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

(replying manually with a cut-n-paste due to a mailing list delivery issue)

> > > > nodes should require higher minimum relay fees for transactions clo=
se 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 transaction=
s (HTLC-preimage / HTLC-timeout),
> when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes wi=
ll automatically go to broadcast an
> on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandw=
idth 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 ordi=
nary
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 entir=
ely
invalid after a point in time. If the transaction isn't mined with reasonab=
ly
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 tha=
t the
> > marginal cost to also use up that bandwidth is low. But that's already =
the case
> > with RBF: we allow any transaction to be replaced with RBF for a (by de=
fault)
> > 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 ad=
ditional
> > 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 introduc=
ed by OP_EXPIRE finality time-bounding semantics.
> However, I think it's more an issue if we introduce things like altruisti=
c re-broadcasting.
> =20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
188.html
> =20
> Certainly, the re-broadcast could favor transactions with higher odds of =
being mined, which naively should match RBF rules.

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

> And by the same way taking time to answer the open questions on this thre=
ad from the old mailing list:
> 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 doe=
s.
>=20
> I've not checked recently, though from research memory a while back the n=
umbers of BIP157 services offering peers
> was in the range of ~10 / 100.
>=20
> One can check by collecting nVersions messages from peers with `NODE_COMP=
ACT_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 mechanism=
s,
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 diff=
erent long running > nodes I have access to, running a variety of Bitcoin C=
ore 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 mi=
n 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 from=
 diverging mempool min fees from the ground iirc.

https://github.com/bitcoin/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. Possibly some
pre-made node distribution is in fact setting non-standard mempool size lim=
its.
Or these are fake spy nodes with unusual behavior.

> > From the point of view of a single node, an attacker can not reuse a UT=
XO in a replacement cycling attack. The BIP125 rules, in particular rule #4=
, ensure that each
> > replacement consumes liquidity because each replacement requires a high=
er 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 t=
ransactions has to pay a higher fee for each victim cycled out. This is bec=
ause at each step of the cycle, the attacker had > to broadcast a transacti=
on with a higher fee than some other transaction.
>=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 initial 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 victim c=
ycled 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 be
pretty straight forward, at which point the attacker is again paying "fairl=
y"
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/Zfmpi/9y4vFMAUtu%40petertodd.org.

--sffbIHzw3cDuBla2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX5qYkACgkQLly11TVR
Lzd7lA//UxIy51duLjJ2V/QKF76QM/hsDacCHOmTfscirc4g+blFRgWq5IpQ8J7n
/JK8BbxxqqSWat0fjAc6HmLBQ6rY9+MAeVYD91CwattAMjqe+ns/Hz4Dlk83wl9P
q083AdrFqS1n8tXFBAq9wNRP54dHAuv44a8rsYkrMi965CWZvT7Q9L7KA7Zn/jpH
qXtK2MuQgS/Dk+7zW78esN0qVf2JsA2cbQiO7Y/ow2l8THTVszgGLXvCPqVRG15Q
VZ46ETpl7Yc6Gi0ztOEWpob0ou8Uw2WPyAKZ4EixUgbNyJ/YB6VipYhVrDXsPjP5
VcNdG8xm8XWlbBK9FmegPH0hlBuFokR1cQUeofNN3sJXbvN0sM6QNGdYc8Afl7NM
0qeD3j14WDaMGQfqyVx5ALcrJyH2Y4XRuq9zD9kGEMd7+FioqiUvrMLV4+oG93UI
6lgC319SuDxNaYeFTDTK/IpYeFWjNXSmtzPNKb7Px8S73tGFVd1em2j4iZ7VqnYY
sW/KsJPFiMPNXx4pWTAzyM2ZeTwQwqVNwwzj7skUYJK9W0EznZBWhczzx2ZefbFA
S/twrbtkpAeJhWKcaTz3g3JSk3igjHPahc4eeZHGSq67tB82QMlxmZaXi4jvBGlZ
yK/OIr0hiZd+uMz+MIyZVaCOi/f+YHi6syOG3BD3GcVXvkv0faE=
=fz0g
-----END PGP SIGNATURE-----

--sffbIHzw3cDuBla2--