From: Greg Maxwell <gmaxwell@gmail.com>
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Brandon Black <freedom@reardencode.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Mon, 20 Oct 2025 15:22:32 +0000 [thread overview]
Message-ID: <CAAS2fgQEdVVcb=DfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng@mail.gmail.com> (raw)
In-Reply-To: <OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 8659 bytes --]
Perhaps it's also worth explicitly pointing out for people following at
home how this proposal has a very real confiscation risk: bare
multisigs can easily violate the proposed limit-- if uncompressed points
are used an "of 8" policy is sufficient, otherwise I think 16 is needed but
both are within the limit of 20 in checkmultisig. This is much worse than
other confiscation concerns that have gummed up most (all?) other cleanup
proposals, because rather than requiring some very contrived thing that
probably no one would have ever done except as lols bare multisigs is a
thing that has actually seen real use and could have been created by
someone doing something completely boring... doubly so because the
inadvertent P2SH script size limit may have explicitly pushed people into
using bare CMS for a large policy when otherwise bare CMS is at least a
little weird.
Aside, some of the confiscatory concerns could be greatly mitigated in
proposals along these lines could be greatly mitigated if the rule was only
applied to transactions which either have no post-activation active
nLocktime or have at least one input with a post activation height. Such a
move could also be done incrementally, limiting it for new coins and then
after giving a longer period to unearth any confiscation risk applying it
more generally if none arises. It still wouldn't completely eliminate a
confiscation risk as there could be an unconfirmed *chain* of transactions,
but perhaps a more limited rule would be easier to argue had an
insignificant risk. Similarly, other such carveouts could be made for more
likely script forms.
One even more conservative possibility would be to trace the "maximum reorg
height" (MRH) of every output, which would be the height of the highest
coinbase transaction in its casual history. If a transaction has any input
with a MRH which is post-activation then it couldn't be part of an
unconfirmed chain that predated the rule activation. The biggest downside
is that implementations don't currently track this metric in their utxo set
and doing so would add a few bytes to each utxo entry and a complete
resync/reindex in order to enforce the rule. I believe this would
essentially eliminate the confiscation risk.
I'd generally say I still think the proposal has little value relative to
the inherent costs of any consensus rule change and potentially has an
unacceptable confiscation risk-- MRH tracking might make that acceptable,
but comes at a high cost which I think would clearly not be justified.
OTOH, MRH tracking might also be attractive for other cleanup proposals
having the similar confiscation risk issues and if so then its cost may be
worthwhile.
I say it has little value because while keeping crap out of the UTXO set
has extremely high value, anyone who wants to stuff crap in will just use
multiple crappy outputs instead which is even worse than using a single big
one especially given that >10k is already unspendable, prunable, and
already pruned by implementations. Worse because each distinct output has
overheads and because even non-op-return becomes prunable if its over 10k
now, while a dozen 520 byte outputs wouldn't be prunable under this
proposal. So, paradoxically this limit might increase the amount of
non-prunable data. A variant that just made >520 unspendable would be
better in this respect, but I doubt it would at all satisfy the proponents'
motivations. Likewise, one that expanded the threshold to more like 1350
would at least avoid the bare CMS concerns but also would probably not
satisfy the proposals proponents.
On Fri, Oct 17, 2025 at 6:45 PM 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
> Hi,
>
> This approach was discussed last year when evaluating the best way to
> mitigate DoS blocks in terms
> of gains compared to confiscatory surface. Limiting the size of created
> scriptPubKeys is not a
> sufficient mitigation on its own, and has a non-trivial confiscatory
> surface.
>
> One of the goal of BIP54 is to address objections to Matt's earlier
> proposal, notably the (in my
> opinion reasonable) confiscation concerns voiced by Russell O'Connor.
> Limiting the size of
> scriptPubKeys would in this regard be moving in the opposite direction.
>
> Various approaches of limiting the size of spent scriptPubKeys were
> discussed, in forms that would
> mitigate the confiscatory surface, to adopt in addition to (what
> eventually became) the BIP54 sigops
> limit. However i decided against including this additional measure in
> BIP54 because:
> - of the inherent complexity of the discussed schemes, which would make it
> hard to reason about
> constructing transactions spending legacy inputs, and equally hard to
> evaluate the reduction of
> the confiscatory surface;
> - more importantly, there is steep diminishing returns to piling on more
> mitigations. The BIP54
> limit on its own prevents an externally-motivated attacker from
> *unevenly* stalling the network
> for dozens of minutes, and a revenue-maximizing miner from regularly
> stalling its competitions
> for dozens of seconds, at a minimized cost in confiscatory surface.
> Additional mitigations reduce
> the worst case validation time by a smaller factor at a higher cost in
> terms of confiscatory
> surface. It "feels right" to further reduce those numbers, but it's less
> clear what the tangible
> gains would be.
>
> Furthermore, it's always possible to get the biggest bang for our buck in
> a first step and going the
> extra mile in a later, more controversial, soft fork. I previously floated
> the idea of a "cleanup
> v2" in private discussions, and i think besides a reduction of the maximum
> scriptPubKey size it
> should feature a consensus-enforced maximum transaction size for the
> reasons stated here:
>
> https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8.
> I wouldn't hold my
> breath on such a "cleanup v2", but it may be useful to have it documented
> somewhere.
>
> I'm trying to not go into much details regarding which mitigations were
> considered in designing
> BIP54, because they are tightly related to the design of various DoS
> blocks. But i'm always happy to
> rehash the decisions made there and (re-)consider alternative approaches
> on the semi-private Delving
> thread [0] dedicated to this purpose. Feel free to ping me to get access
> if i know you.
>
> Best,
> Antoine Poinsot
>
> [0]: https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711
>
>
>
>
> On Friday, October 17th, 2025 at 1:12 PM, Brandon Black <
> freedom@reardencode.com> wrote:
>
> >
> >
> > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
> >
> > > 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 believe this limit would also stop most (all?) of PortlandHODL's
> > DoSblocks without having to make some of the other changes in GCC. I
> > think it's worthwhile to compare this approach to those proposed by
> > Antoine in solving these DoS vectors.
> >
> > Best,
> >
> > --Brandon
> >
> > --
> > 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/aPJ3w6bEoaye3WJ6%40console.
>
> --
> 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/OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc%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/CAAS2fgQEdVVcb%3DDfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10430 bytes --]
next prev parent reply other threads:[~2025-10-20 16:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:42 [bitcoindev] " 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
2025-10-15 20:04 ` [bitcoindev] " Casey Rodarmor
2025-10-16 0:06 ` Greg Maxwell
2025-10-17 17:07 ` Brandon Black
2025-10-17 18:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-10-18 1:01 ` Antoine Riard
2025-10-18 4:03 ` Greg Maxwell
2025-10-18 12:06 ` PortlandHODL
2025-10-18 16:44 ` Greg Tonoski
2025-10-18 16:54 ` /dev /fd0
2025-10-22 8:07 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-27 23:44 ` Michael Tidwell
2025-10-30 2:26 ` Greg Maxwell
2025-10-30 3:36 ` Michael Tidwell
2025-10-30 6:15 ` Greg Maxwell
2025-10-30 8:55 ` Bitcoin Error Log
2025-10-30 17:40 ` Greg Maxwell
2025-10-30 20:27 ` [bitcoindev] Policy restrictions Was: " 'Russell O'Connor' via Bitcoin Development Mailing List
2025-10-30 22:23 ` [bitcoindev] " 'Russell O'Connor' via Bitcoin Development Mailing List
2025-10-30 16:10 ` [bitcoindev] " Tom Harding
2025-10-30 22:15 ` Doctor Buzz
2025-10-20 15:22 ` Greg Maxwell [this message]
2025-10-21 19:05 ` Garlo Nicon
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='CAAS2fgQEdVVcb=DfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng@mail.gmail.com' \
--to=gmaxwell@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=freedom@reardencode.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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