I think that this type of rule is OK if we do it as a "sunsetting" restriction -- e.g. a soft fork active for the next N blocks (N = e.g. 2 years, 5 years, 10 years).
We may yet find a compelling use for larger scriptpubkeys, and to me the interactions between different key types is non-obvious.
An example of where big SPK is valuable v.s. e.g. Taproot, Segwit, P2SH is if there is one big script path required in a two-tx protocol, and the inclusion price must be paid by the proposed of the first tx. In this case, we'd want the inclusion guaranteed by the first tx and then the cost isn't paid (other than satisfaction cost).
You can argue against this example probably, but it is worth considering that absence of evidence of use is not evidence of absence of use and I myself feel that overall our understanding of Bitcoin transaction programming possibilities is still early. If you don't like this example, I can give you others (probably).
As such, I'm NACK on a permanent restriction on what could be a valuable use. But I do think it could be reasonable to set up an auto-renewing restriction on a 1-2 year basis, and allow it to be removed if we later decide we want them.
(N.B. this differs from past temporary soft fork proposals as it's a restriction on something we think no one will do that we eventually lift, rather than removing after a time an opcode that we expect people would want to rely on.)
On Friday, October 3, 2025 at 7:03:09 AM UTC-4 moonsettler 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 <alice...@gmail.com> 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 bitcoindev+...@googlegroups.com.
> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/63c19ec4-ab83-4280-a5b3-037ff1b1b126n%40googlegroups.com.