Bitcoin Forum

BIP 11 makes M-of-N multi-sig transactions standard --- for N <= 3. What is the current support among miners for the multi-sig transactions with N > 3? (say 3-of-6).

Cross-posted from http://bitcoin.stackexchange.com/questions/23274/are-multi-sig-m-of-n-transactions-with-n-3-supported (http://bitcoin.stackexchange.com/questions/23274/are-multi-sig-m-of-n-transactions-with-n-3-supported)

Correct me if I am wrong but P2SH replaced OpEval and thus BIP 11 is "obsolete".

OP_EVAL was subject of BIP 12 and is indeed obsolete. BIP 11 simply standardizes M-of-N for N <= 3. P2SH (BIP 16) extends usage of multi-sig, and much more than that, to my (admittedly limited) understanding.

This is pretty much true, you can do P2SH to support M of N.  However, I believe the limitation of the ScriptSig is 500 bytes to be declared standard, which basically is X of 3 signatures.  Unless I am misreading the source code.  I would like some clarification of this from someone else if they are sure.

Multisig transactions bigger than 3-of-3 are valid but not standard.  This means that doing such transactions is technically valid, and if they show up in the blockchain, they will be accepted by all peers on the network.  However, no peers running unmodified Bitcoin clients will even forward the transactions, and miners will not mine them if they see them.  If you broadcast a 5-of-7 multi-sig transaction (create or spend), it will be DOA to most/all of your peers.

If you want to use them, you must seek out a miner who will agree to mine these transactions for you, and it will take a very long time for it to get into the blockchain.  i.e. if you make an agreement with a miner that represents 0.5% of the total network mining power, it will take an average of 200 blocks (1.3 days) for it to be mined.  It may take a few hours, or a week, depending on that miner's short-term luck.

That's very helpful, thank you very much indeed. Understood re non-forwarding, but does mining these transactions require any additional work/coding for the miners, or any miners out there can add them to the block with no problem if you get the transaction to them?

I know as a matter of direct experiment that this is at least partly incorrect. I've sent several 3 of 4 multisig transactions to random electrum servers and they got picked up fine. (for clarity: spend from 3 of 4 p2sh address transactions)

More to the point, read Peter Todd's response to my query about this here: https://bitcointalk.org/index.php?topic=390046.msg5571289#msg5571289
(you might need to read the conversation before and after)

I'm in the business of trying larger N transactions (M of N, P2SH) now. Some clarity would be nice :)

Thanks! I definitely need to experiment, especially since all tools seem to be provided in the topic you've mentioned.

There are some limitations when creating p2sh addresses. Up to 20 keys can be specified, but there are size limitations with this. All of the keys, and the 'm-of-n' values are encoded in the redeemscript, which has a size limitation. I assume you might be able to specify around 20 compressed keys, perhaps less with uncompressed keys.

Or you send them to Eligius with 17% of the hashing power and it will take an average of 6 blocks to be mined.

Indeed, Eligius solves the problem in one aspect.

However I am confused by the fact that I *can* broadcast 3 of 4 and 2 of 5 transactions to Electrum nodes, and they accept it. This seems to run counter to what people here are saying?

An update for anyone following: to confirm what P Todd said, the transactions seem to pass the "standard" test as long as you keep the scriptSig below 500 bytes (line 519 in main.cpp current version, afaics). This means in practice, for uncompressed pubkeys, that M+N <=7. (~70 bytes for both pubkeys and sigs).

Uncompressed(edit: Compressed) pubkeys will allow one to improve that, I believe, as Peter said (but I haven't done it yet).

There is some higher limit for Eligius but I haven't figured out exactly what it is yet. 6 of 7 worked but 2 of 8 and 6 of 10 didn't.

The problem isn't with the P2SH transaction, but the redeem transaction, which is non-standard if the script is > 500 bytes.  This can lead to some big problems where you make a script that is unspendable, except if you can connect directly to the miners who will mine them.  You don't realize what you have done until it's too late.  There's a solution, but you realize it after the funds are locked up rather than before, which is unfortunate.

Yes, I've just been chatting with Peter Todd to clarify it further and it's a lot clearer. There's two different limits in play; the 500 overall for the scriptsig and the 520 for the redeemscript. What makes it confusing is that to fully understand, you have to combine these two limits with two different notions of correctness: "standard" and "nonstandard". The 500 is required for standard, but the 520 is required for any transaction (valid is perhaps the word?).
As you say there is a big potential issue, for the unaware, of unspendable outputs, Peter is apparently on the case.

Ya just addnode= to Eligius IPs, and use various pusshtx websites, and just keep broadcasting for a bit.  Some non-small number of people relay non-standard tx's and Eligius will mine them.  I've done a handful of non-standard tx's without problem.  The shortest got in the very next block, and the longest took 12 hours, but they all did confirm.  I also had a 0.001 or higher fee for each of them by the way, which may or may not have helped, but I really wanted to "incentivize" miners to make sure the tx got in.

Here's my fix: https://github.com/bitcoin/bitcoin/pull/3843

Makes the RPC interface warn you on >520 bytes, raises the limits on scriptSig's so you can spend any CHECKMULTISIG output, p2sh or otherwise, and also fixes the CHECKMULTISIG dummy value mutability issue.

Under current conditions, would a transaction that has two inputs from 2 of 3 multisig accts, be considered a standard transaction?

The way the rawtransaction is constructed, it seems that you have to duplicate the redeemScript for each of the inputs, even if it is the same for all the vins. This really adds to the size.

Is there a way to specify a single redeemScript to be used on multiple inputs?

James