Topic: Number of m-of-n ouputs per transaction - page 2. (Read 6124 times)

That is possible.  The signature limits are per script so in your example only the 16 of 20 is what matters.   The transaction could have 300 inputs as long as that doesn't violate some other rules You have to use native multisig because due to the 520 byte redeem script limit the largest redeemable P2SH script will be limited to 15 keys.  Make sure you understand the difference between native multisig and P2SH.  Sometimes the term multisig is used generically when refering to P2SH scripts.  Funds requiring P2SH scripts larger than 520 bytes can not be spent (unless a hard fork is done to raise the signature limit) so you can permanently lose funds.


I am not sure if that is not correct or the wording is just not clear.

There are only signatures for inputs (the whole tx is signed but the inputs determine which and how many signatures).

So you have a 16 of 20 multisig address.

To create the MS address will require 20 PubKeyHashes.
To sign transactions with that MS address will require 16 of the 20 private keys which correspond to the PubKeyHashes.
When "receiving"* funds TO that MS address the only signers are the keys which are required to spend the unspent outputs referenced in the input side of the tx.
When "sending"* funds FROM that MS address the only signers are the 16 of 20 specified in the address.

* I generally hate to use wording like that (there is no sending or receiving just inputs and output) but I wanted to make sure it was clear.



I would highly recommend starting first using testnet due to the potential for losing funds.  I would then create some demos on main net funded with token amounts (but above dust limit) before funding with any significant amounts of funds.  There are a lot of potential gotcha, the potential for losing funds is far higher than with "normal" transactions.  Understand my knowledge (especially regarding P2SH) is incomplete and I may be unaware of something critical.  The 520 vs 20 key "incompatibility" caught me off guard (see waxwing post upthread) and that could have resulted in a loss of funds.

You probably should also review this list of limits. https://bitcointalksearch.org/topic/m.6477657   Understand it may not be complete and is a work in progress.

I found this documented demo by Gavin to be helpful (although it is for P2SH not native multisig).  Doing it step by step it was the first time for me that it all "clicked".
https://gist.githubusercontent.com/gavinandresen/3966071/raw/TwoOfThree.sh

Thanks, this is very helpful.

So ignoring IsStandard() for now, I'm looking to construct a transaction with two inputs and a 16-of-20 output, where the 16-of-20 output can be satisfied by any 20 signatories, where none of the 20 are the signatories who sent funds to the input of the transaction.

From what I understand this is possible but want to check this here.

If I've understood this correctly this will therefore involve 22 signatories to create this transaction. Is there anything else I should be aware of?

Correct.  IsStandard() is a check in the bitcoin-core client (and other clients implement similar checks).  If a tx doesn't pass IsStandard then nodes will not relay them (or mine them by default).  The tx is still however valid, so if you can find a miner to include it in a block (either by sending it to them directly, or mining it yourself) the tx and block will still be valid.

So all transactions can be categorized as standard, non-standard, or invalid.

Unfortunately raising the 520 byte limit would require a hard-fork; I don't think we're going to see that issue fixed. We may see it fixed in practice by a future soft-fork implementing a new form of P2SH, perhaps something similar to the original OP_EVAL design.

FWIW when I noticed the issue I pointed it out to some other devs, e.g. gmaxwell, who had never noticed it; I suspect the problem never occurred to Gavin when the P2SH mechanism was designed.

Thanks everyone for this. It's been really helpful and thanks DeathAndTaxes for your concise answers and testing this.

Getting hold of first hand info like this is very useful as I'm not a programmer so some of this can be a bit opaque to me.

DeathAndTaxes: can you clarify what you mean by standard and non-standard but valid? Does this mean for example for a 20-of-20 that some miners may mine this to a block?

Thanks.  Updated my post.  That is a particularly awful "gotcha".  The limit should be raised to 34 * 20 =680 bytes to be inline with the OP_CHECKMULTISIG limit.

So I was able to create a 4-of-6 P2SH on both testnet and main net.
https://blockchain.info/tx/0f1daf1ff4c46b4028095d7862094d560541d7a25d0bd60a927a8987573e8329

Is there a way to determine the IsStandard() output via an API call? 

The redeemscript limit (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520-byte-limitation-on-serialized-script-size) means significantly lower than 20/20 max for non-standard but valid P2SH. I managed 8/15 when I was playing around with it, although I think you might theoretically be able to get 15/15, but someone's got to mine it.

No it's a 20 of 20. 0x14 (base 16) is 20 (base 10)

Nice find, a 14 20-of-20.

Don't you mean 20 of 20: The following transaction is a native 20 of 20 transaction: https://blockchain.info/tx/c4aaf7fbec7a9a079e670e50f6a672315451c7618814494ab1f89cf3fd97b3bb

Making sense now.

Standard
Native MultSig = max 3-of-3 (https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L1414 "if (n < 1 || n > 3)")
P2SH w/ all compressed keys = max of 7-of-15 (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L521 "if(txin.scriptSig.size() > 500)")
P2SH w/ all uncompressed keys = max of 7-of-7 (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L521 "if(txin.scriptSig.size() > 500)")

Non-standard but Valid
Native MultiSig = max of 20-of-20 (update me with line reference of limit for valid OP_CHECKMULTISIG)
P2SH w/ all compressed keys = max of 15-of-15 (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520-byte-limitation-on-serialized-script-size)

Invalid
Native MultiSig = more than 20-of-20
P2SH = more than 15-of-15

Anyone else want to comment on the accuracy of that?

I should have mentioned that earlier. That check applies to outputs (where standard multi-sig pub keys go) only not inputs (where P2SH pub keys go).

So 3 of 3 is the maximum standard normal multi-signature transaction and 4 of 6 is the maximum P2SH transaction.

Because you can cheat at NXT forging. If you have control of a particular block then you can affect who will get to forge blocks in the future. (If you can't affect a future block, then another block between now and that future block must be able to affect it, repeat this argument until you arrive at the future block, someone must have had the final say on who gets to forge it.) Again, this isn't the place for this sort of discussion, post on the conceptcoin subreddit if you want more details of why an independent random source is needed.

I took a look at your link telepatheic.  I don't get why
you would want to use a trusted source for randomness
when you could use a trustless method like NXT does.

DT, any plans for your own altcoin?

This isn't really the place to have that discussion but if you are interested join us at http://www.reddit.com/r/conceptcoin

Well at the same time any altcoin should probably make a few other changes.
1 ) Move signature outside the input (i.e. header, inputs, outputs, signature)
2 ) Make hash for signature the entire tx (forced immutability)
3 ) Enforce a restricted canonical signature (r < half order)
4 ) Always require compressed keys (simplifies encoding, key export, signature verification, etc)
5 ) Use pubkey regeneration to remove the need for pubkeys in the tx input
6 ) Remove edge case tx types (like pay to PubKey vs pay to PubKeyHash)
7 ) Remove unnecessary DER encoding from the blockchain.  Purpose of DER is to allow a standardized format for sharing signatures between applications.  Bitcoin clients don't need that capability.
8 ) Make tx fees explicit.  A nice safety check against malformed txs at the expense of a few bytes (far less than what is saved by removing redundant encoding and pubkeys).
9 ) Make input values explicit.  Makes txn validation by hardware wallets easier.
10) Consider using Schnorr signatures.  Single signature needed for multi-sig making transactions smaller.

It would greatly simplify the codebase with essentially no loss of functionality.  Sadly I don't think such breaking changes will happen with Bitcoin.

That is correct, you also need to add an extra byte to the signature as well technically! The DER encoding is really unnecessary. I'm doing a refactor of bitcoin to get rid of some of these stupid extra bytes.

Doh.  Of Course.

So as long as all 4 keys are compressed then it would look like 4 of 6 meets IsStandard.
4*72 + 6*34 = 492 bytes < 500 bytes

However if any of the keys are uncompressed then it is limited to 3 of 4 keys.
3*72 + 4*66 = 480 bytes < 500 bytes.

I used 34/66 bytes as I believe (going from memory here) the encoding used in tx for the PubKey contains one byte for the length.  Thanks I learned something today.

Actually there is a more restrictive check on the actual script so the max is 3 of 3 (for IsStandard) even if the size is under 500 bytes.
https://github.com/bitcoin/bitcoin/blob/ae7e5d7cebd9466d0c095233c9273e72e88fede1/src/script.cpp#L1414
Only applies to native multisig not P2SH.

This 500 byte limit is in IsStandardTx() check. You can still get your 10-of-20 multisig transaction included in block if your really need it.