Delivery-date: Fri, 03 Oct 2025 08:51:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.152 as permitted sender) client-ip=103.168.172.152;
Feedback-ID: i525146e8:Fastmail
Date: Fri, 3 Oct 2025 13:21:38 +0000
From: Peter Todd <pete@petertodd.org>
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: <aN_N4i4zZ5Dt8TdG@petertodd.org>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="n4uQ4zJDDI/+CqFE"
Content-Disposition: inline
In-Reply-To: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


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

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. 
> 
> This is my gathering of information per BIP 0002
> 
> After doing some research into the number of outpoints that would have 
> violated the proposed rule there are exactly 169 outpoints. With only 8 
> being non OP_RETURN. I think after 15 years and not having discovered use 
> for 'large' ScriptPubkeys; the reward for not invalidating them at the 
> consensus level is lower than the risk of their abuse. 
> 
>    - 
> *Reasons for *
>       - Makes DoS blocks likely impossible to create that would have any 
>       sufficient negative impact on the network.

Further restricting v0 scripts is sufficient to achieve this goal. We do not
need to actually prohibit >520 byte pushes.

>       - Leaves enough room for hooks long term
>       - Would substantially reduce the divergence between consensus  and 
>       relay policy
>       - Incredibly little use onchain as evidenced above.
>       - Could possibly reduce codebase complexity. Legacy Script is largely 
>       considered a mess though this isn't a complete disablement it should reduce 
>       the total surface that is problematic.
>       - Would make it harder to use the ScriptPubkey as a 'large' 
>       datacarrier.
>       - Possible UTXO set size bloat reduction.
>       
>       - *Reasons Against *
>       - Bitcoin could need it in the future? Quantum?

NACK, for exactly this reason. It's hard to predict what kind of math will be
needed in the future for future signature algorithms. With taproot, we include
bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
want to do something similar with >520byte pubkeys for some future signature
algorithm (e.g. quantum hard) or some other difficult to predict technical
upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
this discussion).

>       - Users could just create more outpoints.

The second reason for my NACK. It makes no significant difference whether or
not data is contiguous or split across multiple outputs. All the same concerns
about arbitrary data ("spam") exist and will continue to be argued over even if
we do a soft-fork to prohibit this. All we'll done is have used up valuable dev
and political resources. 

-- 
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/aN_N4i4zZ5Dt8TdG%40petertodd.org.

--n4uQ4zJDDI/+CqFE
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmjfzdcACgkQLly11TVR
LzfsTQ/8DvuJ0NAwjmqYmQV80KV/YBIdFU3Jh4l8ReGMhow8M1glr7BwBnXdergd
ZYaStvdxpXI9WooxY9d2zMzVGpK6kLBKhikaP8yEqDfIepjcJcaElRyNTCgL9Uzx
E0qgCJQCazv1Wjo6N86JR9eiE7JTjtWxaxTmtHIDY3CToJUPlCSpRA9nko6Rta9Z
6JtLYOFSsFfD8sYbd3DY4S71FxBWjMNFYPxJ35jz9l2YdsTVtGGj+9IrUerjGR+R
gs8wky5nuAYVQBllweZ+Kqvxop04rFyTwl1cV9SxZyH6cjhCH0MSUEN197gGWBCd
NgdOhjs/o7qD7ZObqU0c5knZrNGNiT//03G1UlGHqYTxUWBNSOwm9eNo2YjhIZAT
/IetxD2EpULXXjNo3topx4LHyAtwmbHh0lWG/Hi+dm7qrbuRCiZ3j0j4HUemOQZj
J9zS6lBLyBWpyxiTGiaH2FAX+bMirRyYC6hDLmvAIfappjvcHFhGyvwcyL0r7nc2
LDwg9Qo4DpSW6YEA2HubPIUcaaLh6JHNtsS1vxNpKXJtd3oT3UhHXkehQ1NtEaVe
GKVTADHE/QzYQDwhCIEyDp9qNRIjmb2IwZ7o/x3dZY75ERnWhmvplsy7hZx+s3cy
bkJiOaNOjKQBICNJrzKB1Qqn2/jh1uxo/a3ABx5Zsdm4L6PS3ko=
=CE3L
-----END PGP SIGNATURE-----

--n4uQ4zJDDI/+CqFE--