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

From: "/dev /fd0" <[email-masked]>
Date: Fri, 3 Oct 2025 16:56:55 +0530

Hi moonsettler,

> People could just add many OP_RETURNs to a transaction, that makes it
more cumbersome and marginally more expensive.

This is exactly what I wrote in my email and I consider it a positive
thing. I think we are just looking at this proposal from different
perspectives.

/dev/fd0
floppy disk guy

On Fri, Oct 3, 2025 at 4:16 PM moonsettler <[email-masked]>
wrote:

> Hi Floppy,
>
> There are only weak arguments for this proposal to extend to OP_RETURN, at
> least nothing I would normally entertain;
> but also there are weak arguments to make an exception for OP_RETURN
> explicitly.
>
> People could just add many OP_RETURNs to a transaction, that makes it more
> cumbersome and marginally more expensive.
>
> BR,
> moonsettler
>
>
> On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <[email-masked]>
> wrote:
>
> > Hi portlandhodl,
> >
> > We can't predict future usage, so it would be great if this was
> restricted to OP_RETURN. While there is no real use for a scriptPubKey
> larger than 520 bytes as shown in the data you shared, it is possible that
> users may create more OP_RETURN outputs after this change. It does not
> affect the UTXO set but will cost more and economically discourage the use
> of multiple OP_RETURN outputs.
> >
> > /dev/fd0
> > floppy disk guy
> > On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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.
> > >     -   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
> >
> > --
> > 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/842930fb-bede-408a-8380-776d4be4e094n%40googlegroups.com
> .
>

-- 
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/CALiT-Zop43oiYxz1qaLm8RGZHOrd-_antFksY2VfgpzrKqPzCg%40mail.gmail.com.