The rules governing this depend on the type of script used and whether that script is in the output script, in a P2SH, in a P2WSH, or in P2TR. Additionally, the rules are more restrictive for standardness than just validity.
OP_CHECKMULTISIG
allows up to n=20. However there are other limitations due to script size limits that cause n to be smaller.
The alternate constructions of
<pubkey1> OP_CHECKSIG OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD ... OP_SWAP <pubkeyn> OP_CHECKSIG OP_ADD <m> OP_NUMEQUALVERIFY
and
<pubkey1> OP_CHECKSIG <pubkey2> OP_CHECKSIGADD ... <pubkeyn> OP_CHECKSIGADD <m> OP_NUMEQUAL
are only bounded by script size limits.
MuSig2 as specified in the draft BIP allows for up to n=2^32-1 keys. However if you do not follow the standard, it is effectively infinite.
Multisigs in output scripts can use either of the script constructions. In terms of standardness, only OP_CHECKMULTISIG
with up to n=3 is allowed. However in terms of validity, OP_CHECKMULTISIG
can be up to n=20. With the alternate construction, the limit is n=67. This is constrained by the maximum number of non-push operations in the script of 201 operations.
In P2SH, the script is limited for validity by the stack element size limit of 520 bytes. This means n=15 using OP_CHECKMULTISIG
. The alternate construction is limited to n=14. There are no standardness limits that would constrain this.
In P2WSH, the validity limits are the same as bare multisigs. It is limited to n=20 for OP_CHECKMULTISIG
and n=67 with the alternate construction due to the operations limit. There are no standardness limits that would constrain this.
In P2TR, OP_CHECKMULTISIG
is disabled, so only the OP_CHECKSIGADD
construction can be used. There are no standardness limits except for those that apply to the transaction as a whole. Additionally, the validity limits are those that apply to a block as a whole. With the maximum standard transaction weight of 400,000, a transaction could contain a script that uses OP_CHECKSIGADD
that has n=11,759. With the maximum block weight of 4,000,000, n=117,637.
However with P2TR, MuSig is also possible. So those keys could each be a MuSig of 2^32-1 keys (or infinity keys if not using the draft BIP). Furthermore, it is possible to do nested MuSig (MuSig where keys are themselves MuSig), so this would also greatly expand the maximum number of keys that can be involved.
You can get bonuses upto $100 FREE BONUS when you:
π° Install these recommended apps:
π² SocialGood - 100% Crypto Back on Everyday Shopping
π² xPortal - The DeFi For The Next Billion
π² CryptoTab Browser - Lightweight, fast, and ready to mine!
π° Register on these recommended exchanges:
π‘ Binanceπ‘ Bitfinexπ‘ Bitmartπ‘ Bittrexπ‘ Bitget
π‘ CoinExπ‘ Crypto.comπ‘ Gate.ioπ‘ Huobiπ‘ Kucoin.
Comments