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

24

17

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)

ripper234

Posted 2014-03-23T16:51:40.853

Reputation: 25 192

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

almel 2014-07-09T23:19:11.493

Answers

27

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

Pieter Wuille

Posted 2014-03-23T16:51:40.853

Reputation: 54 032

2

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

Steven Roose

Posted 2014-03-23T16:51:40.853

Reputation: 10 855

2When 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 2014-03-24T21:28:27.273

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 2014-03-25T00:16:35.590

1P2SH. Whenever there is a notion of a "multisig address", you know it is P2SH.Steven Roose 2014-04-01T21:42:52.007

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

kolinko

Posted 2014-03-23T16:51:40.853

Reputation: 245

-1

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/

Nagaraj Hubli

Posted 2014-03-23T16:51:40.853

Reputation: 1

3He gave those as arbitrary examples, he didn't mean those are the only possible options...Meni Rosenfeld 2014-05-18T19:35:05.040