From: Garlo Nicon <garlonicon@gmail•com>
To: moonsettler <moonsettler@protonmail•com>
Cc: Andrew Poelstra <apoelstra@wpsoftware•net>,
PortlandHODL <admin@qrsnap•io>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Fri, 3 Oct 2025 09:11:30 +0200 [thread overview]
Message-ID: <CAN7kyNj0zWY8mRtitZNGSrexpQES6U4txswcEgd6BZQUYKX_tw@mail.gmail.com> (raw)
In-Reply-To: <FIpHCygrCyfUu_jNgLJumi-06nYm5P6rmUVc01R3SmhdMVbQo9-8Lyxbh5yGUPrHFQRtyYQ_RvgltQNuoulyXmdnuQSklTab_sM5X63FUs4=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]
> 200 should be enough.
Maybe. But "520" is a battle-tested value, when it comes to the maximum
allowed stack push. Picking "520" should be safe enough, and it has a
higher chances to be accepted as a new consensus rule. Also, if it turns
out, that a lower limit, like "200" is enough, then it can be lowered later
(but bumping it would be much harder).
> If this should apply to OP_RETURN (nulldata) or not, is something I can't
make my mind up on.
I think it should be applied everywhere. And if someone needs a larger
OP_RETURN, then that Script can be taken, wrapped into TapScript branch,
and included to any Taproot address.
pt., 3 paź 2025 o 00:49 'moonsettler' via Bitcoin Development Mailing List <
bitcoindev@googlegroups.com> napisał(a):
> 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.
>
> On Friday, October 3rd, 2025 at 12:31 AM, Andrew Poelstra <
> apoelstra@wpsoftware•net> 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.
> >
> > 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
> >
> > --
> > 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/aN76f2wKPHFcj8qt%40mail.wpsoftware.net
> .
>
> --
> 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/FIpHCygrCyfUu_jNgLJumi-06nYm5P6rmUVc01R3SmhdMVbQo9-8Lyxbh5yGUPrHFQRtyYQ_RvgltQNuoulyXmdnuQSklTab_sM5X63FUs4%3D%40protonmail.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/CAN7kyNj0zWY8mRtitZNGSrexpQES6U4txswcEgd6BZQUYKX_tw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5464 bytes --]
next prev parent reply other threads:[~2025-10-03 8:57 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 [this message]
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
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=CAN7kyNj0zWY8mRtitZNGSrexpQES6U4txswcEgd6BZQUYKX_tw@mail.gmail.com \
--to=garlonicon@gmail$(echo .)com \
--cc=admin@qrsnap$(echo .)io \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=moonsettler@protonmail$(echo .)com \
/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