Delivery-date: Mon, 23 Jun 2025 02:12:08 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 202.12.124.148 as permitted sender) client-ip=202.12.124.148;
Feedback-ID: i525146e8:Fastmail
Date: Fri, 20 Jun 2025 14:28:28 +0000
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>
Cc: James O'Beirne <james.obeirne@gmail.com>,
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Message-ID: <aFVwDLBUJBbHKJLX@petertodd.org>
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net>
 <CAKaEYh+tLtzaqAcN26RLw3AeNhF6VYvMdKrQY6dfCdhYg2Ad3w@mail.gmail.com>
 <b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com>
 <CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com>
 <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="krG4T+Fn4Ucf7yWB"
Content-Disposition: inline
In-Reply-To: <CAB3F3Dsf8=rbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--krG4T+Fn4Ucf7yWB
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Wed, Jun 11, 2025 at 11:33:35AM -0400, Greg Sanders wrote:
> It clearly can be a liability if the relative utility of CTV is damaged by
> a possible future change, even non-consensus ones, some of which are
> already being deployed with non-zero miner support such as
> https://x.com/PortlandHODL/status/1921350395424563572 . This could have led
> to legitimate usage of CTV being trivially DoS'able. Good news is there are
> practical if not beautiful mitigations to this that don't involve annex
> commitment. See https://github.com/bitcoin/bitcoin/pull/32453 and
> https://github.com/petertodd/bitcoin/pull/10 for some relevant details.

Note that in this example the "mitigation" is simply enforcing what is optimal
for miners: mining annexes only when the annexes are required for the
transaction to be valid.

A miner who had allowed standard annexes who was *not* mining CTV transactions
because of a large uncommitted annex is just unnecessarily losing money. They
could easily take that exact transaction, remove the uncommitted annex, and
earn a bit more money. In much the same way that a miner can always do
themselves unnecessary harm by disabling the clean-stack check, and then
failing to mine perfectly valid transactions that would be more profitable if
the extraneous stack elements were removed (modulo non-segwit cases with
high-fee child transactions of course).

It may be a good idea for CTV to commit to annexes. But this issue isn't a
reason to do so.

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

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aFVwDLBUJBbHKJLX%40petertodd.org.

--krG4T+Fn4Ucf7yWB
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmhVcA4ACgkQLly11TVR
LzferQ/+PFiMFOLNFCycIQ0Wd1n2YGGW6YUTBVkk1J0T1tjiwZVOwHK/RsALsVmT
ZaEtvBPP8cWLQSaYezNGUF2VzWUjoiM7zbjUx0hwMG8NhFnxSrJ6QAdn0icqXxLf
l8v6Cx6sOoYZ+sYUVAnQsGDpZ58/b7nrwE60lkXYAS2X1x+owqvWll11CULBEecv
4qGi0w6qtm/nyPl8UdTT9li0bGxlXl5W5uCCncpvU6T2VKeQuccMLQQN8bIzFvRe
DcUEy9YTc3uUpZGhzHXt9LvW1NWvP/09aGP4XETwQOm3km+JFzsigjJjZuNceFxq
osha/wj2jndTGCXubYNPIfYvL/PpYf3AaIm94LV8eIuXwGb9vzQ9fDHLS9FYNoFj
CJopGRYIR9k+ijqYJL25VI1pZ2i+E2UVTpDjAq2sXIaZbh3IGzoWNNeziWiSL2oF
0LvYP1e5Xr9r9nqQRs3c3qgvoR0g+ZKkksrM8jsgXR5uI79N2lwVSI0e4FX0gxCY
sh6Pg+mT8NSV87lAoIYSfodKrdBLjmfIgv15OwE6N3cjD9j9bpr+LHWI92glPhzX
sLUF0zFwJpC2/Ac2JoFpEPfEpZX6V9cwwPtTxR4gCvcg1z6fPmknuJfcN6WNVKJ2
MiPRCgJpfu+l8/aEgg4pRW+kTnGrnxpJMjd/5Ev22cjxPyKXD2c=
=li4V
-----END PGP SIGNATURE-----

--krG4T+Fn4Ucf7yWB--