[BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.

[PortlandHODL]

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.
  • 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?
    
  • Users could just create more outpoints.

Thoughts?

source of onchain data 

PortlandHODL

[Andrew Poelstra]

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.

In any case, if confiscation is a worry, as always we can exempt the
current UTXO set from the rule -- if you are only spending outputs that
existed prior to the new rule, your new UTXOs are allowed to be large.


I would even suggest going lower than 520 bytes.


--
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

[Brandon Black]

Love this idea.

I think "users will just use more outputs" is the one argument against. But with witness size not limited in this way, I don't see that being a problem.

If this avoids any of the fiddliness involved in avoiding DOS with GCC, I think we should do it.

Best,

Brandon

--Brandon, sent by an Android

Oct 2, 2025 15:00:22 PortlandHODL <ad...@qrsnap.io>:

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com.

[Andrew Poelstra]

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.

[moonsettler]

Hi All,

Agreed, this is something we should consider.

> I would even suggest going lower than 520 bytes.

200 should be enough.

If this should apply to OP_RETURN (nulldata) or not, is something I can't make my mind up on.

BR,
moonsettler

Sent with Proton Mail secure email.

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aN76f2wKPHFcj8qt%40mail.wpsoftware.net.