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.
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).
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 standardness, it depends on the version. Up to v0.9.*, the reference client required the total spending script to be at most 500 bytes.
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
https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465 is 15-of-15 p2sh 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).
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.
