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

Because with multisignature you have to put all the possible public keys into the transaction even if they aren't used to sign it. So 4 of 6 requires 4 signatures and 6 public keys.

Looks like you are right.

Actually I believe it is 10 bytes in encoding (DER) + 32 bytes for r, s, x, and y ea.
So for compressed keys the ScriptSig (r, s, x and encoding) is 106 bytes.
For uncompressed keys the ScriptSig (r, s, x, y, and encoding) is 138 bytes.

FLOOR(500 / 106) = 4
FLOOR(500 / 138) = 3

That isn't true. If you read the code, the limit is with the size of sigScript if you are using P2SH:


Signatures are of length 72 bytes and public keys are of length 33 bytes (if compacted) so 4 of 6 is about the limit. I've managed 3 of 4 and it passed as a standard transaction.

This is a critical point.  P2SH makes things easier.  For someone to send you funds you can just provide an address.  The outputs are also smaller (as the output just contains a fixed 32 byte script which contains the hash of the redeemScript).  However P2SH is a double edged sword.  It can make it more difficult for you to spend funds you receive if you create scripts which are non-standard and worse you can even created scripts which are invalid which the network can't verify until funds have already been 'locked up' at that address. See note at the bottom on testing and risk of losing of funds.

'Sending' funds TO a P2SH address
P2SH hash is in the output of the tx
You can have a nearly unlimited number of P2SH addresses as outputs
The output is a fixed length hash of the script.
Actual script not "known" to the network, only "normal" tx validation applies.  
The tx is not significantly different than a "normal" tx.  Instead of putting a hash of the pubkey in the output you are putting a hash of the script in the output.

'Spending' funds FROM a P2SH address
The redeemScript which hashes to the hash in the unspent output's PkScript is added to the ScriptSig portion of the 'spending' transaction's input.
In tx validation the script is hashed and compared to script hash in the prior tx's unspent output.
If that validates then the ScriptSig is validated normally.
The validation rules for scripts apply (see below).  Actually they apply for all scripts but a "normal" (P2PkH script can't exceed the limit).

This is where I think you may still be confused.  With P2SH, an n of m address is simply the HASH of the script.   3 of 3 keys, 7 of 11 keys, 15 of 15 keys, any other arbitrary script.  Instead of the conditions for spending the output being in the output just a hash of that script it placed in the output.  So the direct answer is yes; the size of the script doesn't matter as the output contains a fixed sized hash of the script not the script itself.  However pushes are limited to 520 bytes and since the whole redeemScript needs to be pushed to the stack to validate it's hash any address produced from the hash of a script larger than 520 bytes is effectively unspendable (without a hardfork).

Once again it is important to distinguish funding TO a P2SH address and spending FROM a P2SH address.

For funding a P2SH address (i.e. sending value to the P2SH address, the hash of the script is on the output side of the tx) in all but the most extreme edge cases there are no constraints.   Transactions have no hard size limit (other than they will need to fit in a 1MB block).  To be relayed by most nodes the tx will need to pass IsStandard which limits you to "only" 100KB but with the output being only ~40 bytes you could have thousands of such outputs.  

Now SPENDING FROM a P2SH address is a little more complex as there are restrictions on what scripts are valid and/or standard.   Also see the note at the end about the risk of losing funds due to delayed script validation.  

A tx is invalid if any of the following are true

• Block Size is >1,000 KB (this is a block level check but obviously a tx which can't fit into a block <=1MB could never be confirmed at least not until the 1MB limit is raised).
• A script is >10KB (this is per script so tx can be larger if it contains multiple scripts each less than 10KB).
• The size of the value being pushed in a script is >520 bytes (effectively limits P2SH scripts to 520 bytes as the redeemScript is pushed to the stack).
• The script contains more than 201 operations (excluding pushes).  OP_CHECKMULTISIG with m keys is considered m operations for the purpose of this check.
• The number of keys (n) for a OP_CHECKMULTISIG operation is > 20
• The number of signatures (m) for a OP_CHECKMULTISIG operation is > than number of keys (n)

Your script generation code should validate the script against all validation rules to avoid an "oh shit" moment.  See the warning about loss of funds at the bottom and be sure you understand how the 'delayed validation' of P2SH scripts makes it easier to lose funds.  This doesn't make P2SH bad but it does give you enough rope to hang yourself.  The bolded limitation is the easiest to violate.  Since redeemScripts are pushed to the stack in P2SH input validation the entire script must be less than 520 bytes.  Always do a hard check on the length of your redeemScript.  Don't trust any rule of thumbs.  For example a m-of-15 multisig script is <520 bytes if all keys are uncompressed however if your code accidentally generated one or more uncompressed keys you have now violated the 520 byte limit and created an address which is unspendable.

If the tx is valid but not standard it won't be relayed by most (virtually all) nodes and won't be included in a block by most miners.  To get it confirmed you will need to bypass the peer to peer network and push the transaction directly to a miner who accepts non-standard transactions.  There is no "miner discovery" mechanism in the protocol so you will need to manually check with each miner.   Also the miner may not accept any non-standard txn and may have specific fee requirements so this should only be done if you absolutely can't accomplish the task with standard transactions.  If the transaction is standard it will be relayed automatically by nodes and included in consideration for the next block by most miners so special handling is needed.

A transaction is not standard if any of the following are true

• The tx size > 100KB
• The scriptSig size is > 500 now 1650 bytes.
• The value of any output is less than the dust threshold (5,460 now 546 satoshis).
• The tx is low priority and doesn't include the minimum fee to relay (10,000 now 1,000 satoshis).**
• The tx is not final (nLockTime block has not been created yet).***
• The tx version is greater than the current version (which is 1).
• For 'native' multisig, the number of keys is > 3.
• For P2SH transactions, the number of SigOps is > 15.

** Technically this doesn't make the txn non-standard but even if standard the txn won't be relayed by most nodes if it has insufficient fee or priority so it may help to just consider it part of the IsStandard check.

*** The txn itself is only considered non-standard not invalid but if you include a nlocktime txn with a future nlocktime in a block then the block is invalid.

Note:  It is possible to lose funds with P2SH so extensive testing on testnet is strongly recommended.  The risk comes from the fact that the network is unaware of the script contents at the time the funds are "sent" to the P2SH address.   For a simplistic example create an otherwise valid Bitcoin script which is greater than 10KB in size.  Generate a P2SH address from the hash of the script.  Make a payment to the P2SH address.   The tx sending funds to the P2SH address will validated and be processed by the network without issue.  However any attempt to "spend" the coins sent to the P2SH address will fail as the only valid method of "redeeming" the output is the script and the script breaks the 10KB validation rule.  Those funds can never be spent (or at least can't be spent until the 10KB limit is raised or removed).

If you are sending to P2SH addresses then your initial transaction works just like normal. The usual size, fees and dust limits apply. This is because the P2SH addresses are just regular addresses other than the fact they are a hash of a script instead of the hash of a public key.

Where things can get trickier is in redeeming any of those outputs in subsequent transactions. As stated earlier, the redemption script for a 7-of-11 might be too large.

Thanks, this is what I thought would be the case. I understand there is a byte limit, but not sure if this is a 'hard limit', or just tends to incur fees as I also understand that there are fees (by consensus) associated with transactions over a certain byte size. E.g. if you create a transaction that aggregates many small inputs and this takes up a lot of data on the blockchain then it incurs a fee.

So, assuming the inputs are always more than or equal to the outputs, my questions are:

1. It is possible to have multiple m-of-n contracts as outputs for a transaction? From what I understand this should be possible but costly due to the bytes required to script the transaction.

2. Is there a size above which a miner (by consensus) will not mine a transaction to a block? You mention the number of bytes that are allowed? Is there a hard limit here or does the fee just increase above a certain byte size in relation to how many extra bytes are required to write the transaction to the blockchain?

3. I have been told that their is a hard limit of 20-of-20 for any given contract, as per the source code in version 0.8. I have also now read that their is a limit of 16-of-16 which is true? Or is it more complicated than that?

Yes as long as the outputs don't exceed the the value amount of the inputs. There are some other rules that that restrict you thou, a 7-11 redeem script would be huge, and may exceed the amount of bytes that is allowed.

I should have been clearer:

Its no different to a normal transactions limits on the number of vouts. They wouldn't be on the same contract. Each vout is separate to the rest.

Whysis you think it would be different?

How many m-of-n contracts can exsist as outputs for a transaction?

For example can I have a 3BTC input and spend 1BTC to a 2-of-3, 1BTC to a 5-of-5 and 1BTC to a 7-of-11 on the same contract transaction?

Or can only 1 m-of-n exsist per transaction?