<p>from 0-of-0 upto 20-of-20</p>

<p><a href="https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52" rel="noreferrer">https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52</a>
is 0-of-0 p2sh redeemption</p>

<p><a href="https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc" rel="noreferrer">https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc</a>
if 20-of-20 bare multisig redeemption</p>

<p><a href="https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465" rel="noreferrer">https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465</a>
is 15-of-15 p2sh redeemption</p>

CC BY-SA 3.0
2014-10-16T21:11:38.637Z
https://blockchain.info/tx/56214420a7c4dcc4832944298d169a75e93acf9721f00656b2ee0e4d194f9970 is relevant too.
morsecoder
CC BY-SA 3.0
2014-06-23T04:25:00.440Z
2014-06-23T04:30:26.530Z
2014-06-23T04:30:26.530Z
amaclin
<p>I recently implemented <a href="https://github.com/dartcoin/dartcoin-lib/blob/master/lib/src/script/standard/multisig_output.dart" rel="nofollow">multi-sig outputs</a> for <a href="https://github.com/dartcoin/dartcoin-lib" rel="nofollow">Dartcoin</a>, using the <a href="https://code.google.com/p/bitcoinj/" rel="nofollow">BitcoinJ</a> implementation as a reference.</p>

<p>It seems that the reference client has a maximum of 3 keys for multisig transactions. However, the actual limit is 16. This limit is not arbitrary (like the 3 key limit is), but is due to the hard limit of the script limit.</p>

<p>Using more than 3 keys works exactly the same as with 3 keys. As you can see in the code, the output just consists of the number of keys you provide (n) and the threshold for spending (m).</p>

CC BY-SA 3.0
2014-03-24T21:28:27.273Z
When using P2SH (which the OP is, given the linked method), there is no limit of 3 keys. This is only enforced for raw multisig.
Pieter Wuille
CC BY-SA 3.0
2014-03-25T00:16:35.590Z
What's the limit when you create a P2SH multisig address? I guess it depends on the size of the input you need to create to spend it.
Steven Roose
CC BY-SA 3.0
2014-04-01T21:32:32.697Z
So, which method does this use, P2SH or raw? https://bitcoin.stackexchange.com/questions/3712/how-can-i-create-a-multi-signature-2-of-3-transaction/10593#10593
ripper234
CC BY-SA 3.0
2014-04-01T21:42:52.007Z
P2SH. Whenever there is a notion of a "multisig address", you know it is P2SH.
Steven Roose
CC BY-SA 3.0
2014-03-24T10:30:21.710Z
2014-03-24T10:30:21.710Z
Steven Roose
<p>We've tested p2sh multisigs up to 8-of-15. Above 15, bitcoind caused problems.</p>

<p>You can review our code here, to see how it's done:</p>

<p><a href="https://github.com/orisi/orisi" rel="nofollow">https://github.com/orisi/orisi</a></p>

<p>There's also a project discussion here, with some interesting tidbits:</p>

<p><a href="https://bitcointalk.org/index.php?topic=645589.0" rel="nofollow">https://bitcointalk.org/index.php?topic=645589.0</a></p>

<p>Currently the problem is that anything above 3 of 3 exceeds the standard transaction size and we have to push it through Eligius pool. But from people said in the thread, there is a way to compress the keys and make even 8 of 15 st</p>

CC BY-SA 3.0
2014-06-23T17:20:54.623Z
2014-06-23T17:20:54.623Z
kolinko
<p>As per the below article by Vitalik Buterin, theoretically, you can have one-of-three, five-of-five, or six-of-eleven multisig addresses, it just happens that two-of-three is the most useful combination.</p>

<p><a href="http://bitcoinmagazine.com/11108/multisig-future-bitcoin/" rel="nofollow">http://bitcoinmagazine.com/11108/multisig-future-bitcoin/</a></p>

CC BY-SA 3.0
2014-05-18T19:35:05.040Z
He gave those as arbitrary examples, he didn't mean those are the only possible options...
Meni Rosenfeld
CC BY-SA 3.0
2014-03-24T20:33:00.617Z
2014-03-24T20:33:00.617Z
Nagaraj Hubli
<p>We need to distinguish the limitations for <strong>validity</strong> and <strong>standardness</strong>. The first is determined by the consensus rules (which cannot change without a hard fork). The second ones are determined by local relay and mining policies implemented in the reference client, and can change from version to version.</p>

<p>In addition, we need to distinguish <strong>raw</strong> multisig (a simple OP_CHECKMULTISIG based script), and <strong>P2SH</strong> multisig (where the OP_CHECKMULTISIG script is only revealed upon spending).</p>

<p>Finally, because scripts include public keys, their sizes depend on their lengths. Both compressed (33 bytes) and uncompressed (65 bytes) keys exist, depending on which version of a wallet was used to generate them.</p>

<h1>Raw multisig</h1>

<p>Every m-of-n combination is <strong>valid</strong> (up to n=20), but <strong>standardness</strong> rules only allow up to n=3.</p>

<p>This limitation is enforced when sending (i.e., sending to a 2-of-4 multisig will not be considered standard).</p>

<h1>P2SH multisig</h1>

<p><strong>validity</strong> rules require that the P2SH redeem script is at most 520 bytes. As the redeem script is [m pubkey1 pubkey2 ... n OP_CHECKMULTISIG], it follows that the length of all public keys together plus the number of public keys must not be over 517.</p>

<ul>
<li>For compressed public keys, this means up to n=15</li>
<li>For uncompressed ones, up to n=7.</li>
</ul>

<p>For <strong>standardness</strong>, it depends on the version. Up to v0.9.*, the reference client required the total spending script to be at most 500 bytes.</p>

<ul>
<li>For compressed keys, this means m*73 + n*34 &lt;= 496 (up to 1-of-12, 2-of-10, 3-of-8 or 4-of-6).</li>
<li>For uncompressed keys, this means m*73 + n*66 &lt;= 496 (up to 1-of-6, 2-of-5, 3-of-4).</li>
</ul>

<p>In 0.10, these standardness rules will likely be relaxed, allowing to go up to the validity limits (15-of-15 for compressed keys, 7-of-7 for uncompressed keys).</p>

<p>Also, for P2SH, standardness and validity restrictions are only applied when spending (as the spending script is only revealed at that time). This may mean that sending your coins to a P2SH script may make them irrecoverably lost (especially when violating a validity rule).</p>

CC BY-SA 3.0
2014-06-22T23:43:44.993Z
2014-12-08T14:43:53.157Z
2014-12-08T14:43:53.157Z
Pieter Wuille
<p><a href="https://bitcoin.stackexchange.com/a/10593/78">This method</a> describes how to create a 2-of-3 multisig.</p>

<p>I heard that there is an inherent limit with the number of multisig parts, limiting them to 3.</p>

<p>Does the standard method described above of <strong>generating</strong> and <strong>spending</strong> multisig addresses work with more than 3 parts? What is the limit? How to work around that and create/spend larger multisigs using bitcoind (practical 'how to' would be appreciated)</p>

CC BY-SA 3.0
2014-07-09T23:19:11.493Z
This post includes a step by step tutorial for how to create and spend a multisig address.https://bitcoin.stackexchange.com/questions/6100/how-will-multisig-addresses-work
almel
<multi-signature>
What are the limits of m and n in m-of-n multisig addresses?
ripper234
# What are the limits of m and n in m-of-n multisig addresses?

(Asked by: username_0 on 2014-03-23)

[This method](https://bitcoin.stackexchange.com/a/10593/78) describes how to create a 2-of-3 multisig.

I heard that there is an inherent limit with the number of multisig parts, limiting them to 3.

Does the standard method described above of **generating** and **spending** multisig addresses work with more than 3 parts? What is the limit? How to work around that and create/spend larger multisigs using bitcoind (practical 'how to' would be appreciated)

**Tags:** multi-signature

> **Comments:**
> **username_1**: This post includes a step by step tutorial for how to create and spend a multisig address.https://bitcoin.stackexchange.com/questions/6100/how-will-multisig-addresses-work  

---

## 5 answers

### Answer by username_5 on 2014-06-22. Score: 34 | Accepted answer

We need to distinguish the limitations for **validity** and **standardness**. The first is determined by the consensus rules (which cannot change without a hard fork). The second ones are determined by local relay and mining policies implemented in the reference client, and can change from version to version.

In addition, we need to distinguish **raw** multisig (a simple OP\_CHECKMULTISIG based script), and **P2SH** multisig (where the OP\_CHECKMULTISIG script is only revealed upon spending).

Finally, because scripts include public keys, their sizes depend on their lengths. Both compressed (33 bytes) and uncompressed (65 bytes) keys exist, depending on which version of a wallet was used to generate them.

# Raw multisig

Every m-of-n combination is **valid** (up to n=20), but **standardness** rules only allow up to n=3.

This limitation is enforced when sending (i.e., sending to a 2-of-4 multisig will not be considered standard).

# P2SH multisig

**validity** rules require that the P2SH redeem script is at most 520 bytes. As the redeem script is [m pubkey1 pubkey2 ... n OP\_CHECKMULTISIG], it follows that the length of all public keys together plus the number of public keys must not be over 517.

* For compressed public keys, this means up to n=15
* For uncompressed ones, up to n=7.

For **standardness**, it depends on the version. Up to v0.9.\*, the reference client required the total spending script to be at most 500 bytes.

* For compressed keys, this means m\*73 + n\*34 <= 496 (up to 1-of-12, 2-of-10, 3-of-8 or 4-of-6).
* For uncompressed keys, this means m\*73 + n\*66 <= 496 (up to 1-of-6, 2-of-5, 3-of-4).

In 0.10, these standardness rules will likely be relaxed, allowing to go up to the validity limits (15-of-15 for compressed keys, 7-of-7 for uncompressed keys).

Also, for P2SH, standardness and validity restrictions are only applied when spending (as the spending script is only revealed at that time). This may mean that sending your coins to a P2SH script may make them irrecoverably lost (especially when violating a validity rule).


---

### Answer by username_2 on 2014-06-23. Score: 7

from 0-of-0 upto 20-of-20

<https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52>
is 0-of-0 p2sh redeemption

<https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc>
if 20-of-20 bare multisig redeemption

<https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465>
is 15-of-15 p2sh redeemption

> **Comments:**
> **username_3**: https://blockchain.info/tx/56214420a7c4dcc4832944298d169a75e93acf9721f00656b2ee0e4d194f9970 is relevant too.  

---

### Answer by username_4 on 2014-03-24. Score: 2

I recently implemented [multi-sig outputs](https://github.com/dartcoin/dartcoin-lib/blob/master/lib/src/script/standard/multisig_output.dart) for [Dartcoin](https://github.com/dartcoin/dartcoin-lib), using the [BitcoinJ](https://code.google.com/p/bitcoinj/) implementation as a reference.

It seems that the reference client has a maximum of 3 keys for multisig transactions. However, the actual limit is 16. This limit is not arbitrary (like the 3 key limit is), but is due to the hard limit of the script limit.

Using more than 3 keys works exactly the same as with 3 keys. As you can see in the code, the output just consists of the number of keys you provide (n) and the threshold for spending (m).

> **Comments:**
> **username_5**: When using P2SH (which the OP is, given the linked method), there is no limit of 3 keys. This is only enforced for raw multisig.  
> **username_4**: What's the limit when you create a P2SH multisig address? I guess it depends on the size of the input you need to create to spend it.  
> **username_0**: So, which method does this use, P2SH or raw? https://bitcoin.stackexchange.com/questions/3712/how-can-i-create-a-multi-signature-2-of-3-transaction/10593#10593  
> **username_4**: P2SH. Whenever there is a notion of a "multisig address", you know it is P2SH.  

---

### Answer by username_6 on 2014-06-23. Score: 2

We've tested p2sh multisigs up to 8-of-15. Above 15, bitcoind caused problems.

You can review our code here, to see how it's done:

<https://github.com/orisi/orisi>

There's also a project discussion here, with some interesting tidbits:

<https://bitcointalk.org/index.php?topic=645589.0>

Currently the problem is that anything above 3 of 3 exceeds the standard transaction size and we have to push it through Eligius pool. But from people said in the thread, there is a way to compress the keys and make even 8 of 15 st


---

### Answer by username_7 on 2014-03-24. Score: -2

As per the below article by Vitalik Buterin, theoretically, you can have one-of-three, five-of-five, or six-of-eleven multisig addresses, it just happens that two-of-three is the most useful combination.

<http://bitcoinmagazine.com/11108/multisig-future-bitcoin/>

> **Comments:**
> **username_8**: He gave those as arbitrary examples, he didn't mean those are the only possible options...  

---

