Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.

From: Luke Dashjr <[email-masked]>
Date: Fri, 3 Oct 2025 16:02:42 -0400

If we're going this route, we should just close all the gaps for the 
immediate future:

- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem 
terrible. UTXOs are a huge cost to nodes, we should always keep them as 
small as possible. Anything else can be hashed (if SHA256 is broken, we 
need a hardfork anyway).

- Limit script data pushes to 256 bytes, with an exception for BIP16 
redeem scripts.

- Make undefined witness/taproot versions invalid, including the annex 
and OP_SUCCESS*. To make any legitimate usage of them, we need a 
softfork anyway (see below about expiring this).

- Limit taproot control block to 257 bytes (128 scripts max), or at 
least way less than it currently is. 340e36 scripts is completely 
unrealistic.

- Make OP_IF invalid inside Tapscript. It should be unnecessary with 
taproot, and has only(?) seen abuse.

We can do these all together in a temporary softfork that self-expires 
after a year or two. This would buy time to come up with longer-term 
solutions, and observe how it impacts the real world. Since it expires, 
other softforks making use of upgradable mechanisms can just wait it out 
for those mechanisms to become available again - therefore we basically 
lose nothing. (This is intended to buy us time, not as a permanent fix.)

Alternatively, but much more complex, we could redesign the block weight 
metric so the above limits could be exceeded, but at a higher 
weight-per-byte; perhaps weigh data 25% more per byte beyond the 
expected size. This could also be a temporary softfork, perhaps with a 
rolling window, so future softforks could be free to lower weights 
should they be needed.

Another idea might be to increase the weight based on 
coin-days-destroyed/coin-age, so rapid churn has a higher feerate than 
occasional settlements. But this risks encouraging UTXO bloat, so needs 
careful consideration to proceed further.

Happy to throw together a BIP and/or code if there's community support 
for this.

Luke

On 10/2/25 16:42, 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
>     *
>       o Makes DoS blocks likely impossible to create that would have
>         any sufficient negative impact on the network.
>       o Leaves enough room for hooks long term
>       o Would substantially reduce the divergence between consensus 
>         and relay policy
>       o Incredibly little use onchain as evidenced above.
>       o 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.
>       o Would make it harder to use the ScriptPubkey as a 'large'
>         datacarrier.
>       o Possible UTXO set size bloat reduction.
>
>   * *Reasons Against *
>       o Bitcoin could need it in the future? Quantum?
>       o Users could just create more outpoints.
>
> Thoughts?
>
> source of onchain data 
> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
>
> PortlandHODL
>
> -- 
> 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 [email-masked].
> To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com 
> <https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org.