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)

up vote 19 down vote accepted

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

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

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

  • 3
    He gave those as arbitrary examples, he didn't mean those are the only possible options... – Meni Rosenfeld May 18 '14 at 19:35

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.