# What are the limits of m and n in m-of-n multisig addresses?

This method 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)

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).

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

I recently implemented multi-sig outputs for Dartcoin, using the 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).

• 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. Commented Mar 24, 2014 at 21:28
• 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. Commented Mar 25, 2014 at 0:16
• So, which method does this use, P2SH or raw? bitcoin.stackexchange.com/questions/3712/… Commented Apr 1, 2014 at 21:32
• P2SH. Whenever there is a notion of a "multisig address", you know it is P2SH. Commented Apr 1, 2014 at 21:42

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

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/

• He gave those as arbitrary examples, he didn't mean those are the only possible options... Commented May 18, 2014 at 19:35