That concern is why the annex exists, I believe. But taproot aside, that is a point.

But also given that there are essentially no violations and no reason to expect any I'm not sure the proposal is worth time relative to fixes of actual moderately serious DOS attack issues.

I guess a fair point is that given the ongoing progress towards consensus rules being the boundary of what gets mined, it would be nice to prevent big outputs that would bloat the utxo set. OTOH any output over 10k is already pruned in implementations (as spending it is consensus invalid), so the gap here is really just between 520 and 10k.

But even if jumbo outputs were being created today I think they'd still be a less pressing issue than several of the other consensus cleanup issues.

On Wed, Oct 15, 2025 at 11:45 PM Casey Rodarmor <casey@rodarmor.com> wrote:

I think that "Bitcoin could need it in the future?" might be a good enough
reason not to do this.

Script pubkeys are the only variable-length transaction fields which can be
covered by input signatures, which might make them useful for future soft
forks. I can imagine confidential asset schemes or post-quantum coin recovery
schemes requiring large proofs in the outputs, where the validity of the proof
determined whether or not the transaction is valid, and thus require the
proofs to be in the outputs, and not just a hash commitment.
On Thursday, October 2, 2025 at 2:59:24 PM UTC-7 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/961e3c3a-a627-4a07-ae81-eb01f7a375a1n%40googlegroups.com.