<p>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.</p>
<p><code>OP_CHECKMULTISIG</code> allows up to n=20. However there are other limitations due to script size limits that cause n to be smaller.</p>
<p>The alternate constructions of</p>
<pre><code>&lt;pubkey1&gt; OP_CHECKSIG OP_SWAP &lt;pubkey2&gt; OP_CHECKSIG OP_ADD ... OP_SWAP &lt;pubkeyn&gt; OP_CHECKSIG OP_ADD &lt;m&gt; OP_NUMEQUALVERIFY
</code></pre>
<p>and</p>
<pre><code>&lt;pubkey1&gt; OP_CHECKSIG &lt;pubkey2&gt; OP_CHECKSIGADD ... &lt;pubkeyn&gt; OP_CHECKSIGADD &lt;m&gt; OP_NUMEQUAL
</code></pre>
<p>are only bounded by script size limits.</p>
<p>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.</p>
<hr />
<p>Multisigs in output scripts can use either of the script constructions. In terms of standardness, only <code>OP_CHECKMULTISIG</code> with up to n=3 is allowed. However in terms of validity, <code>OP_CHECKMULTISIG</code> 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.</p>
<p>In P2SH, the script is limited for validity by the stack element size limit of 520 bytes. This means n=15 using <code>OP_CHECKMULTISIG</code>. The alternate construction is limited to n=14. There are no standardness limits that would constrain this.</p>
<p>In P2WSH, the validity limits are the same as bare multisigs. It is limited to n=20 for <code>OP_CHECKMULTISIG</code> and n=67 with the alternate construction due to the operations limit. There are no standardness limits that would constrain this.</p>
<p>In P2TR, <code>OP_CHECKMULTISIG</code> is disabled, so only the <code>OP_CHECKSIGADD</code> 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 <code>OP_CHECKSIGADD</code> that has n=11,759. With the maximum block weight of 4,000,000, n=117,637.</p>
<p>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.</p>

CC BY-SA 4.0
2022-06-12T02:31:57.970Z
2022-07-06T11:24:11.137Z
2022-07-06T11:24:11.137Z
Ava Chow
<p>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.</p>
<p>What are the limits of N for this application?</p>
<p>What is the technical cause of this limitation? Is it blockspace? Limitations of Script? Or some other reason?</p>
<p>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.</p>

<multi-signature><p2sh><p2pkh><p2wpkh><p2tr>
What is the largest multisig quorum currently possible?
Matthias
# What is the largest multisig quorum currently possible?

(Asked by: username_0 on 2022-06-11)

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.

**Tags:** multi-signature, p2sh, p2pkh, p2wpkh, p2tr


---

## 1 answers

### Answer by username_1 on 2022-06-12. Score: 10

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.


---

