From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Brandon Black <freedom@reardencode.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Fri, 17 Oct 2025 18:05:25 +0000 [thread overview]
Message-ID: <OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=@protonmail.com> (raw)
In-Reply-To: <aPJ3w6bEoaye3WJ6@console>
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.
next prev parent reply other threads:[~2025-10-17 18:45 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 [this message]
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
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='OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=@protonmail.com' \
--to=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