> bare multisigs can easily violate the proposed limit

Good point. I can imagine a Script, which could allow something like 1-of-460 multisig: if all public keys would be hashed, then it would take 21 bytes to push any given hash. And then, pushing 460 hashes would take 460*21=9660 bytes. Then, to clean it up, OP_2DROP would consume two elements, so that means 230 bytes, to clean it up with OP_2DROPs, and a single OP_DROP.

I think it could be something like that:

OP_TOALTSTACK <9660 bytes> OP_FROMALTSTACK OP_PICK OP_TOALTSTACK
<OP_2DROP*229> OP_DROP
OP_DUP OP_HASH160 OP_FROMALTSTACK OP_EQUALVERIFY OP_CHECKSIG

And then, this is how it could be executed:

<sig> <pubkey> <number>                    //input stack
<sig> <pubkey>                             //toaltstack
<sig> <pubkey> <lots_of_hashes>            //pushing hashes
<sig> <pubkey> <lots_of_hashes> <number>   //pushing number
<sig> <pubkey> <lots_of_hashes> <hash>     //picking hash
<sig> <pubkey> <lots_of_hashes>            //toaltstack
<sig> <pubkey>                             //dropping the rest
<sig> <pubkey> <pubkey>                    //dup
<sig> <pubkey> <hash>                      //hash160
<sig> <pubkey> <hash> <hash>               //fromaltstack
<sig> <pubkey>                             //equalverify
OP_TRUE                                    //checksig

Which means, that it would take 9660 bytes, plus 230 bytes of dropping, so it sums up to 9890 bytes. Then, 9 bytes are consumed by the rest of the envelope, and that leaves 101 bytes for signature and public key. Seems doable. But I didn't check it in regtest yet.

pon., 20 paź 2025 o 18:48 Greg Maxwell <gmaxwell@gmail.com> napisał(a):
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.

--
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/CAN7kyNi2xxEY1LZTb_WMXKtFiDf8Epi3VN7HLhsNimOAEMH1xg%40mail.gmail.com.