From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Peter Todd <pete@petertodd•org>
Cc: PortlandHODL <admin@qrsnap•io>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Fri, 03 Oct 2025 16:52:51 +0000 [thread overview]
Message-ID: <ONFWceYdQT0aizGwn2vyyzdr2RZ9GlQ7vAfNfIRRO_IGsTaX-l3bghNiygjXmccG8UJO_7pxrAr2ZKbUrlvNrAZ83EfyPjzuAR26J7xp4bw=@protonmail.com> (raw)
In-Reply-To: <aN_N4i4zZ5Dt8TdG@petertodd.org>
> NACK, for exactly this reason. It's hard to predict what kind of math will be
> needed in the future for future signature algorithms. With taproot, we include
> bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
> want to do something similar with >520byte pubkeys for some future signature
>
> algorithm (e.g. quantum hard) or some other difficult to predict technical
> upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
>
> this discussion).
No matter how large a pubkey script you need, you can just delegate to the
witness if you have a cryptographically secure hash function.
Hard to even imagine needing anywhere near 4096 bits for that.
The going assumption for quantum algos is they could halve the bit strength of
a hash function, but SHA512 seems quiet robust even under worst assumptions.
And it's not enough to find ANY collision for a script or some Merkle root.
Putting the unlocking conditions into the UTXO set does not seem like a healthy
idea to me anyhow.
BR,
moonsettler
PS:
No hard opinion on temporary vs final restrictions. I wouldn't worry about it.
Sent with Proton Mail secure email.
On Friday, October 3rd, 2025 at 5:51 PM, Peter Todd <pete@petertodd•org> 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.
> >
> > 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.
>
>
> Further restricting v0 scripts is sufficient to achieve this goal. We do not
> need to actually prohibit >520 byte pushes.
>
> > - 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?
>
>
> NACK, for exactly this reason. It's hard to predict what kind of math will be
> needed in the future for future signature algorithms. With taproot, we include
> bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
> want to do something similar with >520byte pubkeys for some future signature
>
> algorithm (e.g. quantum hard) or some other difficult to predict technical
> upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
>
> this discussion).
>
> > - Users could just create more outpoints.
>
>
> The second reason for my NACK. It makes no significant difference whether or
> not data is contiguous or split across multiple outputs. All the same concerns
> about arbitrary data ("spam") exist and will continue to be argued over even if
> we do a soft-fork to prohibit this. All we'll done is have used up valuable dev
> and political resources.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> 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/aN_N4i4zZ5Dt8TdG%40petertodd.org.
--
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/ONFWceYdQT0aizGwn2vyyzdr2RZ9GlQ7vAfNfIRRO_IGsTaX-l3bghNiygjXmccG8UJO_7pxrAr2ZKbUrlvNrAZ83EfyPjzuAR26J7xp4bw%3D%40protonmail.com.
next prev parent reply other threads:[~2025-10-03 17:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:42 PortlandHODL
2025-10-02 22:19 ` Andrew Poelstra
2025-10-02 22:46 ` Andrew Poelstra
2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 7:11 ` Garlo Nicon
2025-10-02 22:27 ` Brandon Black
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 11:26 ` /dev /fd0
2025-10-03 13:35 ` jeremy
2025-10-03 13:59 ` Andrew Poelstra
2025-10-03 14:18 ` /dev /fd0
2025-10-03 14:59 ` Andrew Poelstra
2025-10-03 16:15 ` Anthony Towns
2025-10-03 13:21 ` [bitcoindev] " Peter Todd
2025-10-03 16:52 ` 'moonsettler' via Bitcoin Development Mailing List [this message]
2025-10-03 15:42 ` Anthony Towns
2025-10-03 20:02 ` Luke Dashjr
2025-10-03 20:52 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ONFWceYdQT0aizGwn2vyyzdr2RZ9GlQ7vAfNfIRRO_IGsTaX-l3bghNiygjXmccG8UJO_7pxrAr2ZKbUrlvNrAZ83EfyPjzuAR26J7xp4bw=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=admin@qrsnap$(echo .)io \
--cc=moonsettler@protonmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox