Bitcoin script allows for a UTXO to be (un)encumbered by an N-of-N signature. When N is 1, this is referred to as a single signature.
What are the limits of N for this application?
What is the technical cause of this limitation? Is it blockspace? Limitations of Script? Or some other reason?
Coordinating large amounts of people is often failure prone, inconvenient and confusing. For simplicity, let’s assume the involved users are all well-behaved and competent.
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.
