Delivery-date: Thu, 02 Oct 2025 15:49:25 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) client-ip=66.183.0.127;
Date: Thu, 2 Oct 2025 22:46:53 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: PortlandHODL <admin@qrsnap.io>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Message-ID: <aN8A3TnDiwiNlunQ@mail.wpsoftware.net>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
 <aN76f2wKPHFcj8qt@mail.wpsoftware.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="h4oK5F+TT+SYF/09"
Content-Disposition: inline
In-Reply-To: <aN76f2wKPHFcj8qt@mail.wpsoftware.net>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--h4oK5F+TT+SYF/09
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Thu, Oct 02, 2025 at 10:19:43PM +0000, Andrew Poelstra wrote:
> On Thu, Oct 02, 2025 at 01:42:06PM -0700, PortlandHODL wrote:
> > Proposing: Softfork to after (n) block height; the creation of outpoints 
> > with greater than 520 bytes in the ScriptPubkey would be consensus invalid. 
> >
> 
> Personally, I like this. Unlike restrictions on opcode behavior or
> witness data, it is impossible for there to be any existing UTXOs which
> "might turn out to need" scriptpubkeys greater than 520 bytes. In a
> post-covenant world I suppose this could change.
> 
> There is a risk of confiscation of coins which have pre-signed but
> unpublished transactions spending them to new outputs with large
> scriptPubKeys. Due to long-standing standardness rules, and the presence
> of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> such transactions exist.
>

To add to this -- if we whitelisted existing UTXOs to preserve the
validity of pre-signed transactions, this still might not be enough;
there could be arbitrarily long chains of pre-signed transaction.

This is still possible to overcome -- we whitelist all existing UTXOs,
their descendants (UTXOs created from transactions which only spend
existing UTXOs), and so on. The result would be that from the point
of activation, new coinbase outputs would have limited size, as would
their children, and so on, and the limit would spread outward.

I don't think this is a great idea -- it would be technically hard to
implement and slow deployment indefinitely. But I am bringing it up
so people are aware that it's possible to address the confiscation
issue, no matter how rigid you are about it.


-- 
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

-- 
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/aN8A3TnDiwiNlunQ%40mail.wpsoftware.net.

--h4oK5F+TT+SYF/09
Content-Type: application/pgp-signature; name=signature.asc

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

iQEzBAEBCgAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmjfANsACgkQxYjWPOQb
l8Fvdgf8CAYJDdVQ+ALVBPxfICCeAyaolhJwndC/eImYRmQNl9g2CrlDaJBYi/2X
QkrucJetVdGg6sxivAmHBPS88fu07fjvIYyisgcJNk/DWfnSgr2EG/TbaruVsmWH
NZwQ+OIw0bfOWt/5xlzsVeagCJD2EdF4g1eEPg3lA/wD2pfBAYSU2OIBgyQQK5FU
0VHRD4D3IlB1gqwd/Ccvck2YH69TnER471xUImoFe/GA5jaa82cfYNyxX3GmZBFZ
L5ayxixqEZzo0QsV5/8aFv1C3MI0Vqz9fp4/VoJTk1tF7UGROxMYxrIyxPEb34Ae
S6HjvVwyVMbix5EqsgOUZXl95D7SxQ==
=b8u2
-----END PGP SIGNATURE-----

--h4oK5F+TT+SYF/09--