<blockquote>
  <p>By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).</p>
</blockquote>

<p>That's correct. Even though the <code>OP_CHECKMULTISIG</code> script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.</p>

<blockquote>
  <p>However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.</p>
</blockquote>

<p>BIP141 only describes the consensus rules - i.e. what transactions are valid inside blocks. There are a number of standardness rules that apply for transactions to be relayed and accepted into memory pools, to avoid potential avenues of abuse before they're understood. Bitcoin Core 0.13.1 and up limit witness scripts to 3600 bytes for that purpose.</p>

<blockquote>
  <p>For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?</p>
  
  <p><code>0x01 0x32 &lt;100 signatures&gt; 0x01 0x64 OP_CHECKMULTISIG</code></p>
</blockquote>

<p>I assume you mean public keys there instead of signatures?</p>

<p>No. OP_CHECKMULTISIG itself only supports up to 20-of-20, so if you want to use that opcode, you can't go above 20. However, you can construct others scripts that go above those limits.</p>

<p>In particular:</p>

<pre><code>&lt;pubkey1&gt; OP_CHECKSIG
OP_SWAP &lt;pubkey2&gt; OP_CHECKSIG OP_ADD
OP_SWAP &lt;pubkey3&gt; OP_CHECKSIG OP_ADD
...
OP_SWAP &lt;pubkey67&gt; OP_CHECKSIG OP_ADD
&lt;m&gt; OP_NUMEQUALVERIFY
</code></pre>

<p>would implement an m-of-67 policy, with less than 3600 bytes.</p>

CC BY-SA 3.0
2017-02-28T09:55:10.870Z
Thank you for your great answer. Yes, I meant "100 public keys", I fixed it in the original question.
Simone Bronzini
CC BY-SA 3.0
2017-02-28T10:06:57.733Z
So, if I understand your alternative solution correctly, 10000-byte scripts would allow for multisig addresses with `n` as great as 276 (i.e. `floor((10,000 - 34 - 3) / 36)`, where the first line is 34 bytes, the last line is 3 bytes, considering `m` as an OP_PUSHDATA1 followed by a one-byte number, and every other line is 36 bytes), is that correct?
Simone Bronzini
CC BY-SA 3.0
2017-02-28T13:58:04.193Z
Yes, but that would exceed the 201 script ops limit.
Pieter Wuille
CC BY-SA 3.0
2017-02-28T14:30:45.650Z
Isn't it too late to enlarge the limit for witness scripts? (I am just asking, I do not need this increasing) And what about the limit of 20 sigop operations for a script?
amaclin
CC BY-SA 3.0
2017-02-28T14:34:05.943Z
Any of these limits can easily be changed in a new software version (for standardness limits like 3600 bytes) or a new script version (for consensus limits like 10k bytes or 201 ops). Given the script versioning that segwit introduces, the latter should be simple.
Pieter Wuille
CC BY-SA 4.0
2017-02-26T08:21:05.227Z
2018-11-20T18:24:36.017Z
2018-11-20T18:24:36.017Z
Pieter Wuille
<p>By reading <a href="https://bitcoin.stackexchange.com/a/28092/46388">this answer</a>, I understand that in m-of-n multisig addresses, <code>m</code> and <code>n</code> are limited by the maximum size allowed by the P2SH <code>redeemScript</code> (i.e. 520 bytes).</p>

<p>However, in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program" rel="noreferrer">this section</a> of BIP141, it is stated that the <code>witnessScript</code> can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large <code>m</code> and <code>n</code> that will be considered valid.</p>

<p>By my calculations we will be able to have <code>n</code>s as big as around 300. Am I understanding this correctly?</p>

<p>For instance, would the following <code>witnessScript</code>, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?</p>

<pre><code>0x01 0x32 &lt;100 public keys&gt; 0x01 0x64 OP_CHECKMULTISIG
</code></pre>

<multi-signature><segregated-witness>
Will SegWit allow for m of n multisig with very large n and m?
Simone Bronzini
# Will SegWit allow for m of n multisig with very large n and m?

(Asked by: username_0 on 2017-02-21)

By reading [this answer](https://bitcoin.stackexchange.com/a/28092/46388), I understand that in m-of-n multisig addresses, `m` and `n` are limited by the maximum size allowed by the P2SH `redeemScript` (i.e. 520 bytes).

However, in [this section](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program) of BIP141, it is stated that the `witnessScript` can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large `m` and `n` that will be considered valid.

By my calculations we will be able to have `n`s as big as around 300. Am I understanding this correctly?

For instance, would the following `witnessScript`, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?

```
0x01 0x32 <100 public keys> 0x01 0x64 OP_CHECKMULTISIG

```

**Tags:** multi-signature, segregated-witness


---

## 1 answers

### Answer by username_1 on 2017-02-26. Score: 13 | Accepted answer

> By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).

That's correct. Even though the `OP_CHECKMULTISIG` script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.

> However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.

BIP141 only describes the consensus rules - i.e. what transactions are valid inside blocks. There are a number of standardness rules that apply for transactions to be relayed and accepted into memory pools, to avoid potential avenues of abuse before they're understood. Bitcoin Core 0.13.1 and up limit witness scripts to 3600 bytes for that purpose.

> For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?
>
> `0x01 0x32 <100 signatures> 0x01 0x64 OP_CHECKMULTISIG`

I assume you mean public keys there instead of signatures?

No. OP\_CHECKMULTISIG itself only supports up to 20-of-20, so if you want to use that opcode, you can't go above 20. However, you can construct others scripts that go above those limits.

In particular:

```
<pubkey1> OP_CHECKSIG
OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD
OP_SWAP <pubkey3> OP_CHECKSIG OP_ADD
...
OP_SWAP <pubkey67> OP_CHECKSIG OP_ADD
<m> OP_NUMEQUALVERIFY

```

would implement an m-of-67 policy, with less than 3600 bytes.

> **Comments:**
> **username_0**: Thank you for your great answer. Yes, I meant "100 public keys", I fixed it in the original question.  
> **username_0**: So, if I understand your alternative solution correctly, 10000-byte scripts would allow for multisig addresses with `n` as great as 276 (i.e. `floor((10,000 - 34 - 3) / 36)`, where the first line is 34 bytes, the last line is 3 bytes, considering `m` as an OP_PUSHDATA1 followed by a one-byte number, and every other line is 36 bytes), is that correct?  
> **username_1**: Yes, but that would exceed the 201 script ops limit.  
> **username_2**: Isn't it too late to enlarge the limit for witness scripts? (I am just asking, I do not need this increasing) And what about the limit of 20 sigop operations for a script?  
> **username_1**: Any of these limits can easily be changed in a new software version (for standardness limits like 3600 bytes) or a new script version (for consensus limits like 10k bytes or 201 ops). Given the script versioning that segwit introduces, the latter should be simple.  

---

