Delivery-date: Tue, 12 Mar 2024 22:10:46 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 as permitted sender) client-ip=103.168.172.157;
Feedback-ID: i525146e8:Fastmail
Date: Wed, 13 Mar 2024 03:32:05 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] OP_Expire mempool behavior
Message-ID: <ZfEeNcX3ebyuYYRi@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mDr+lEMoqAV+gaM5"
Content-Disposition: inline
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--mDr+lEMoqAV+gaM5
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 t=
o
> > their expiration height to ensure we don=E2=80=99t waste bandwidth on t=
ransactions
> > that have no potential to be mined
>
> This seems insufficient to solve the problem, unless the premium is so hi=
gh
> 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_EXPI=
RE simply
> waste blockspace? If however the feerate of the transaction is merely
> competitive, the presence of OP_EXPIRE creates a bandwidth-wasting vector=
: an
> attacker would submit e.g. OP_EXPIRE transactions at the bottom of the to=
p
> block and push them out of the top block with further OP_EXPIRE transacti=
ons.
> This way the attacker could issue a constant stream of transactions, but
> 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 in =
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 th=
e
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 defaul=
t)
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 additi=
onal
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/ZfEeNcX3ebyuYYRi%40petertodd.org.

--mDr+lEMoqAV+gaM5
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmXxHjMACgkQLly11TVR
LzcoYA//YtkGk5R5s1SusXTI7cCSbeAj4eslEV73mGXm+1LERpHiZRDbXRdwuvbH
L/xSIK92uVOL8u+nD6s3Ym3RgZ2/t9zEMfKliWh84x2XIQdG8zi0oOmjKLb6XtT8
Ztr77ued8ngCCl0b9fxtbbvWz1iGRUy+aFxUKb+zA+tG2F8IBDJ3etNkxl33+Hf+
wNkt6hN+vFURX2xOA+wmly0VrxVXjZ9fLMMpTEKs3G28wDjPSosWiySWit7RX1R2
fgyFxDGrkAl05CnIO4qJcKPdh2rpGSi+UUlXJouocJtnOgt9fgI/FEpnrEbiAfjy
oIVp9U8MB2UpwaH/8ENc172BiY/o1bda0THxQJ7Yb+1wbhrWdjbRjrhzO1J7Wp6x
JRyJhCCCxd1Nn8wjFM0/rn/twM3HiRuJFtJtJJ4uGzZ54eDAEQL/RNamY0hnIf8X
xiRdITdQh4CMMxeoB4LGEIOsqC5KQEYRYpt0CxTNPGnUdQXs/AsRMux2kFYKP+VH
RtNMEpOw7kLL6XfDwFeK6Pe6FKHftRJS2XiyCiqd1tuShDQdSwkuzOAxBP+W/BSC
1nD24FRYgjMG8Fr6SmPepjiM8j/1jR9ILi+ChWtEnFqFNWEGbGQ3lsFfE2q3cyPO
R6MXI059SF+7xbHdS1/bdBU2lzkwsM5JP+BNHWZza7Vah08Fook=
=V2AP
-----END PGP SIGNATURE-----

--mDr+lEMoqAV+gaM5--