From: Keagan McClelland <keagan.mcclelland@gmail•com>
To: Greg Tonoski <greg.tonoski@gmail•com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Wed, 8 Oct 2025 12:15:08 -0600 [thread overview]
Message-ID: <CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com> (raw)
In-Reply-To: <CAMHHROwJA5N=SfejF353oWFFsKVCtk5cpr9QkOv+ZcqGDFz6oA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8427 bytes --]
Hard NACK on capping the witness size as that would effectively ban large
scripts even in the P2SH wrapper which undermines Bitcoin's ability to be
an effectively programmable money.
The issue is that if you do that then you effectively make script unusable
for complex scripting or anything related to ZKPs. At that point you may as
well just remove script altogether and just make Bitcoin a key-only
currency, which I think would be silly. I think making Bitcoin safely more
programmable should be the goal, not hamstringing what can be done with
script by capping the witness size. The "spam" (which I'll remind people is
an incoherent idea in a leaderless system) is a symptom of the inability
for a robust fee market to develop for block space.
I am hesitant to limit the scriptPubKey all the way down to 67 bytes.
Although it may be compelling to tighten it up as restrictively as
possible, if we find a reason to increase it again, it either has to be
done via a hard fork or via a significantly more complicated and subversive
mechanism. I think a gradual tightening based off of concrete observations
in the wild is a much more prudent approach.
Keags
On Wed, Oct 8, 2025 at 10:24 AM Greg Tonoski <greg.tonoski@gmail•com> wrote:
> I'm for all the consensus proposals below and would further specify:
> - limiting the maximum size of the scriptPubKey of a transaction to 67
> bytes (to keep supporting P2PK and avoid impacting usability/compatibility
> of old, deprecated software and risk of similar corner cases); good
> riddance to P2MS;
> - limit the maximum size of script data pushes to 73 bytes (for the same
> reason, i.e. keep supporting for P2PK input: signature with its encoding
> overhead; also P2PKH) "with an exception for BIP16 redeem scripts [which
> may embed multiple public keys for multisig]",
> - rule out "OP_FALSE OP_IF" (CVE-2023-50428),
> - discontinue P2SPAM (the one that repurposed the mnemonic OP_RETURN and
> was standardized in 2014, commit a79342479f577013f2fd2573fb32585d6f4981b3
> <https://github.com/bitcoinknots/bitcoin/commit/a79342479f577013f2fd2573fb32585d6f4981b3>
> ).
>
> BTW I think we should also consider consensus-wise limit on the maximum
> size of the so-called Witness field (3600 bytes max. by policy.h) along
> with max. size (80 bytes max. by policy.h) and max. count of its items (100
> by policy.h). Any suggestions, anybody?
>
> --
> Greg Tonoski
>
> On Fri, Oct 3, 2025 at 10:09 PM Luke Dashjr <luke@dashjr•org> wrote:
>
>> If we're going this route, we should just close all the gaps for the
>> immediate future:
>>
>> - Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem
>> terrible. UTXOs are a huge cost to nodes, we should always keep them as
>> small as possible. Anything else can be hashed (if SHA256 is broken, we
>> need a hardfork anyway).
>>
>> - Limit script data pushes to 256 bytes, with an exception for BIP16
>> redeem scripts.
>>
>> - Make undefined witness/taproot versions invalid, including the annex
>> and OP_SUCCESS*. To make any legitimate usage of them, we need a softfork
>> anyway (see below about expiring this).
>>
>> - Limit taproot control block to 257 bytes (128 scripts max), or at least
>> way less than it currently is. 340e36 scripts is completely unrealistic.
>>
>> - Make OP_IF invalid inside Tapscript. It should be unnecessary with
>> taproot, and has only(?) seen abuse.
>>
>> We can do these all together in a temporary softfork that self-expires
>> after a year or two. This would buy time to come up with longer-term
>> solutions, and observe how it impacts the real world. Since it expires,
>> other softforks making use of upgradable mechanisms can just wait it out
>> for those mechanisms to become available again - therefore we basically
>> lose nothing. (This is intended to buy us time, not as a permanent fix.)
>>
>> Alternatively, but much more complex, we could redesign the block weight
>> metric so the above limits could be exceeded, but at a higher
>> weight-per-byte; perhaps weigh data 25% more per byte beyond the expected
>> size. This could also be a temporary softfork, perhaps with a rolling
>> window, so future softforks could be free to lower weights should they be
>> needed.
>>
>> Another idea might be to increase the weight based on
>> coin-days-destroyed/coin-age, so rapid churn has a higher feerate than
>> occasional settlements. But this risks encouraging UTXO bloat, so needs
>> careful consideration to proceed further.
>>
>> Happy to throw together a BIP and/or code if there's community support
>> for this.
>>
>> Luke
>>
>>
>> On 10/2/25 16:42, 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
>> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
>>
>> 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/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> 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/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org
>> <https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAMHHROwJA5N%3DSfejF353oWFFsKVCtk5cpr9QkOv%2BZcqGDFz6oA%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAMHHROwJA5N%3DSfejF353oWFFsKVCtk5cpr9QkOv%2BZcqGDFz6oA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALeFGL0PDjtRt2rfbY4gTkoc%2B5oNQ0mn_obraE7PrtHuNYFpQw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10586 bytes --]
prev parent reply other threads:[~2025-10-08 18:17 UTC|newest]
Thread overview: 24+ 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-05 9:59 ` Guus Ellenkamp
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
2025-10-04 23:12 ` jeremy
2025-10-05 10:59 ` Luke Dashjr
2025-10-08 15:03 ` Greg Tonoski
2025-10-08 18:15 ` Keagan McClelland [this message]
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=CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com \
--to=keagan.mcclelland@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=greg.tonoski@gmail$(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