Enforcing 'n' signatories & signing order for m-of-n P2SH Vs. Multisig

[hhanh00]

Yes to all your questions.

[DannyHamilton]

I've had a look around but can't find a definitive answer to my previous question.

Talking only about P2SH:

I understand that this is a hash of the script which needs to evaluate to True when run and is provided in the input of the transaction that spends it.

Is this input script stored in full in the input of the transaction which spends it when the transaction is mined to the blockchain?

Yes.

In the case where OP_CHECKMULTISIG is used in the script are all the public keys and Scriptsigs stored in the input of the new transaction?

Yes.

I also take it a transaction with one or more P2SH inputs that has one or more P2SH outputs is standard? Assuming each script is below 1,650 bytes and the total transaction is below 100,000 bytes.

Yes.

[No_2]

Thanks for your patience in letting me check this through with you, I really appreciate it guys.

Now talking only about Multisig:

The Multisig script in a transaction output contains a series of values which must be satisfied, one per signatory. Are these just the public keys of the signatories?

If so is there a way for a malicious signatory to change the order or value of these private keys if say there were two inputs to this transaction which two spate parties needed to sign?

Edit for clarification: that is to say could one party sign to release the first input, modify the transaction and then pass it to the second party to sign and release the second input.

[hhanh00]

The signatures used in multisig are produced the same way single signatures are created. Consequently, if someone modifies the transaction it invalidates any signature that was made on the original transaction.

Edit: The blockchain doesn't see the intermediate steps. It only sees the completed and signed transaction.

[No_2]

Thanks. I thought it was something like that. I knew there needed to be a dependency so as to prevent the transaction being editable but I was not sure what it was.

So each input signature provided in the input is a signature of the new transaction's outputs? I'm guessing the signatures cannot include the inputs as these each need to be signed and would therefore result in different signatures being generated each time.

[CoinTop]

Been looking for this myself

[hhanh00]

Yes, in most cases the signature covers the entire new transaction (minus the signature itself and the pub scripts you are not signing). The exact process is complicated.
It's worth knowing that the signer can choose to sign a portion of the transaction and therefore allow some changes to it.

[No_2]

Great, thanks.

So, correct me if I've got this wrong: In a scenario where a signatory to a Multisig transaction can only see that transaction and they are expecting a specific number of signatories and a specific signing order they can verify the transaction is configured correctly before they sign. P2SH is not suitable for this scenario because the signatories and signing order is obfuscated by the hashing of the script. Furthermore for Multisig if you already know the signatories' private keys you can verify who the signatories are.

These should be my last questions:

1. If redeemed successfully am I correct in assuming that the valid Scriptsigs will be written into the redeeming transaction's input? If so are the public keys included here as well as they are already in the previous transaction's outputs?

2. I also take it a transaction with one or more Multisig inputs that has one or more Multisig outputs is standard? Assuming each output script is below 1,650 bytes and the total transaction is below 100,000 bytes.

3. I'm assuming there are no plans to discontinue Multisig as it is OP_CHECKMULTISIG which is used by other types of scripts, P2SH being one example.

4. Can I also check: that the public key is stored in a full, usable format on the blockchain in transaction input? I.e. it  would be usable in the above scenario i.e. you can see who the associated signatories are in the above situation if the public key has been used previously?

[DannyHamilton]

I'm guessing the signatures cannot include the inputs as these each need to be signed and would therefore result in different signatures being generated each time.

Actually, the signatures do include the inputs, they just don't include the signatures on the inputs.

An input includes 3 pieces of information:

• The transaction ID (SHA256 hash) of the transaction that created the unspent output that is being used as an input
• The "vout" of the specific unspent output that is being used from that transaction (A transaction could have more than 1 output, "vout" is used to indicate which of those outputs is being spent.  The first output of a transaction is a "vout" of 0, the second is vout of 1, the third is vout of 2, and so on.
• The ScriptSig. This is the data that is applied to the ScriptPubKey of the output being spent that causes that ScriptPubKey to evaluate as 'True'

The only part of this that is not included in the signature is the ScriptSig.

The Multisig script in a transaction output contains a series of values which must be satisfied, one per signatory. Are these just the public keys of the signatories?

No.

First of all, most bitcoin transactions use a hash of a public key and not the public key itself.

Secondly, a script is just that... A script (essentially a computer program or set of instructions).  It has instructions and data.  You can read more about it and get a better understanding of the instructions available here:
https://en.bitcoin.it/wiki/Script

Each instruction is typically a single byte code.  Data can be more than 1 byte (such as a signature or a public key hash) So, when you send bitcoins to a typical address (starting with a 1), the actual transaction output script has the following information in the ScriptPubKey:

• OP_DUP (value=0x76) An instruction to duplicate the top stack item
• OP_HASH160 (value=0xa9) An instruction to hash the top stack item twice, first with SHA-256 and then with RIPEMD-160
• 0x14 (decimal value 20) (All values between 0x01 and 0x4b are an indication of how many of the following bytes should be pushed to the stack. A RIPEMD-160 hashed bitcoin address is exactly 20 bytes long, therefore in a version 1 address this value will always be 0x14)
• 20 bytes of hashed public key
• OP_EQUALVERIFY (value 0x88) An instruction to check that the top two values on the stack are equal and make the transaction invalid if they are not
• OP_CHECKSIG (value=0xac) An instruction to hash the transaction and verify that the signature provided on the stack is the correct signature for the transaction.

[DannyHamilton]

Great, thanks.

So, correct me if I've got this wrong: In a scenario where a signatory to a Multisig transaction can only see that transaction and they are expecting a specific number of signatories and a specific signing order they can verify the transaction is configured correctly before they sign.

They would need to be able to see both the output being redeemed AND the transaction that is redeeming it.

P2SH is not suitable for this scenario because the signatories and signing order is obfuscated by the hashing of the script.

It is still suitable, but the signatories all need the script given to them.  They won't be able to get it from the blockchain.  Without the script, it is impossible to create a valid input since the script must be included as a part of the input.  If they are provided the redeeming transaction (which they are being asked to sign), then they have been provided with the unhashed script since it is part of the input of that transaction.

Furthermore for Multisig if you already know the signatories' private keys you can verify who the signatories are.

I assume you mean public keys?  You shouldn't know anyone's private keys other than your own.

1. If redeemed successfully am I correct in assuming that the valid Scriptsigs will be written into the redeeming transaction's input?

Yes.  If they are not, then it is not a valid transaction and all peers and miners will reject it.

If so are the public keys included here as well as they are already in the previous transaction's outputs?

If it is P2SH, then the entire missing portion of the script must be included in the ScriptSig as part of the input.

If is is P2PKH, then the script is already available in the ScriptPubKey of the previous transaction's output.

2. I also take it a transaction with one or more Multisig inputs that has one or more Multisig outputs is standard? Assuming each output script is below 1,650 bytes and the total transaction is below 100,000 bytes.

Yes.

3. I'm assuming there are no plans to discontinue Multisig as it is OP_CHECKMULTISIG which is used by other types of scripts, P2SH being one example.

That would be a forking change. I don't think it will be possible to get consensus on such a change, therefore it almost certainly won't happen.

4. Can I also check: that the public key is stored in a full, usable format on the blockchain in transaction input? I.e. it  would be usable in the above scenario i.e. you can see who the associated signatories are in the above situation if the public key has been used previously?

Certainly.  If you know who controls the private key that is associated with the public key, then you will know who the signatory is.  If you don't know who controls the private key that is associated with the public key, then all you know is that the signature provided was provided by a person that has access to the private key that is associated with the public key.

[hhanh00]

Great, thanks.

So, correct me if I've got this wrong: In a scenario where a signatory to a Multisig transaction can only see that transaction and they are expecting a specific number of signatories and a specific signing order they can verify the transaction is configured correctly before they sign. P2SH is not suitable for this scenario because the signatories and signing order is obfuscated by the hashing of the script. Furthermore for Multisig if you already know the signatories' private keys you can verify who the signatories are.

You mean public keys, don't you?

These should be my last questions:

1. If redeemed successfully am I correct in assuming that the valid Scriptsigs will be written into the redeeming transaction's input? If so are the public keys included here as well as they are already in the previous transaction's outputs?

Only the signatures

2. I also take it a transaction with one or more Multisig inputs that has one or more Multisig outputs is standard? Assuming each output script is below 1,650 bytes and the total transaction is below 100,000 bytes.

Yes

3. I'm assuming there are no plans to discontinue Multisig as it is OP_CHECKMULTISIG which is used by other types of scripts, P2SH being one example.

I don't see why it would be removed

4. Can I also check: that the public key is stored in a full, usable format on the blockchain in transaction input? So is would for example usable in the above scenario i.e. you can see who the associated signatories are in the above situation if the public key has been used previously?

Yes you can. If a signature used a pub key, the node needed it to validate the tx. Therefore you can see it too.

[DeathAndTaxes]

I'm guessing the signatures cannot include the inputs as these each need to be signed and would therefore result in different signatures being generated each time.

Well (like everything in Bitcoin) it is complicated.  There is something called the SIGHASH which defines what part of the txn is signed.  Normally SIGHASH_ALL is used which means that 'almost' everything is signed.   So if you have a txn with 3 inputs and 4 outputs and for input 1 the SIGHASH_ALL is used then all 3 inputs and 4 outputs are signed.

The one exception is the ScriptSig portion of the input.  Since it contains the signature obviously it can't be part of what is signed.  So a placeholder is used, the hash of all 3 inputs and 4 outputs is computed, the hash is signed and then the ScriptSig placeholder is replaced with the actual Sig (and anything else required to validate the unspent output referenced in that input.   Then input #2 and #3 and processed the same way (depending on what their SIGHASH is).

[No_2]

...

The Multisig script in a transaction output contains a series of values which must be satisfied, one per signatory. Are these just the public keys of the signatories?

No.
...

Whoops, should have phrased that more clearly: Is the Multisig script in a transaction output a series of public keys, one per signatory?

…
It is still suitable, but the signatories all need the script given to them.  They won't be able to get it from the blockchain.  Without the script, it is impossible to create a valid input since the script must be included as a part of the input.  If they are provided the redeeming transaction (which they are being asked to sign), then they have been provided with the unhashed script since it is part of the input of that transaction.
…

So the use-case I'm talking about here is that two parties are each going to sign one input for a transaction with two 'basic' inputs (i.e. they just require a sig and pubkey to be spent) and a Multisig output. That is the only information they have apart from the blockchain and they need to verify:

• The number of signatures
• The order of signatories
• That those signatories are who they think they are based on previous public keys used on the blockchain

From what I understand, with the current transaction and no other information this is possible.

For this use-case P2SH is not suitable because the signatures are obfuscated by the hashing of the script. P2SH only becomes suitable if the original script is known the the two parties signing the inputs. Or have I misunderstood something, for example the full script would have to be know to them to sign the transaction inputs?

I assume you mean public keys?  You shouldn't know anyone's private keys other than your own.

You mean public keys, don't you?

Whoops, yes: I meant public keys.

Only the signatures

Thanks.

Certainly.  If you know who controls the private key that is associated with the public key, then you will know who the signatory is.  If you don't know who controls the private key that is associated with the public key, then all you know is that the signature provided was provided by a person that has access to the private key that is associated with the public key.

Yes you can. If a signature used a pub key, the node needed it to validate the tx. Therefore you can see it too.

Brilliant.

[No_2]

...
Well (like everything in Bitcoin) it is complicated.  There is something called the SIGHASH which defines what part of the txn is signed.  Normally SIGHASH_ALL is used which means that 'almost' everything is signed.   So if you have a txn with 3 inputs and 4 outputs and for input 1 the SIGHASH_ALL is used then all 3 inputs and 4 outputs are signed.
...

Thanks. I thought it would be something like that. The dependencies I can see are:

1. It needs to prove the signatory is the one authorising the release of the funds.
2. The signatory expects the transaction to match this signature, effectively 'locking it in place'.

[DeathAndTaxes]

3. I'm assuming there are no plans to discontinue Multisig as it is OP_CHECKMULTISIG which is used by other types of scripts, P2SH being one example.

Discointinue?  No.  It could be done but it would require a soft fork.   However native (i.e. non P2SH) multisig is not particularly user friendly.  To have someone 'pay to' a complex script (which is what multisig is) and not a scriptHash (P2SH) means you have no address to give the sender.  Most wallets can't send a payments without an address.  Most users will have no idea how to pay you.

Imagine you tried to buy something online and instead of a Bitcoin address you saw:

Code:

Thank you for your order.  Please send 1 BTC to

52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240eb3d31b1266f69f5767071aa3 e017d1b82a0bb28dab5e27d4d8e9725b3e68ed5f8a2d45c730621e34104cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4410461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af53ae

While you 'can' construct a txn which has this as the PkScript of one of the outputs there is no checksum so any copying problems would result in lost coins.  You can't use most GUI wallets to construct the transaction.  You can't lookup the transaction by 'address' using a block explorer as it has no address. This script (3-of-3 multisig) is standard but anything more complex or even just using 4+ keys is non-standard and will not be relayed by most nodes.  The cost of your script size is also paid for by the sender, so the more complex your script is (great for you) the more expensive it is for someone else to send you funds (not so good for them).

So while you should know that the PkScript can contain any script you wish it makes a lot more sense to make the output a standard P2SH output containing the hash of that script.
* You can provider sender with just an address.
* Any user can send funds from pretty much any wallet without issue (many won't even know it is not a 'normal' address).
* Transaction size and thus fees are lower for sender although your spending txn is equally larger.
* It works the way a user 'expects it to' (how most users think Bitcoin works and how it actually works is often different).
* The funding txn will pass IsStandard() and be relayed by all nodes (if it is otherwise standard as well).
* You can use a much larger set of possible scripts without problems (max of 520 bytes).

[DeathAndTaxes]

For this use-case P2SH is not suitable because the signatures are obfuscated by the hashing of the script. P2SH only becomes suitable if the original script is known the the two parties signing the inputs. Or have I misunderstood something, for example the full script would have to be know to them to sign the transaction inputs?

So give the user a copy of the script along with the unsigned transaction.  Almost all PkScripts can be converted into a P2SH output.  The only significant limitation is that P2SH are limited to 520 bytes because pushes to the stack of more than 520 bytes are not valid.  The bad news is we likely will have that limitation for a while as changing it would require a hard fork.

[No_2]

I wanted to check one more thing. When funds are redeemed from a P2SH multisig output of a transaction on the blockchain the input of the new transaction spending them specifies in its inputs:

• The original ScriptPubKey in full, who's hash gave the P2SH address in the output of the previous transaction (less the checksum and proceeding '3' identifier)
• Because the P2SH address uses OP_CHECKMULTISIG this script, now provided in full, will specify a series of PubKeyHashes to a total of 'n' from the set of m-of-n required to sign
• To satisfy the ScriptPubKey the PubKeys are provided in full (i.e. are not PubKeyHashes) for 'm' of those PubKeyHashes, now used to redeem the funds to this new transaction

This information in the transaction input is eventually written to the blockchain in full and remains there in the public ledger.

Assuming I have the above correct my question is: With only the information stored on the blockchain it possible to tell which set of PubKeys actually signed, i.e. can I tell who makes up the 'm' subset of the 'n' signatures who signed to release funds? I'm assuming it is because their PubKey's are provided in full in this new transaction's input?

[amaclin]

The only significant limitation is that P2SH are limited to 520 bytes because pushes to the stack of more than 520 bytes are not valid.
The bad news is we likely will have that limitation for a while as changing it would require a hard fork.

Do the current consensus code accepts blocks with pushes over than 520 bytes?
(I think yes, but not sure)

[DeathAndTaxes]

The only significant limitation is that P2SH are limited to 520 bytes because pushes to the stack of more than 520 bytes are not valid.
The bad news is we likely will have that limitation for a while as changing it would require a hard fork.

Do the current consensus code accepts blocks with pushes over than 520 bytes?
(I think yes, but not sure)

No the blocks are invalid because they contain invalid txns.   This is not a "IsStandard() check it is an valid vs invalid check. A block containing a txn with a push larger than 520 bytes is no more valid than one containing a coinbase generation of 500,000 new Bitcoins. 

[hhanh00]

Assuming I have the above correct my question is: With only the information stored on the blockchain it possible to tell which set of PubKeys actually signed, i.e. can I tell who makes up the 'm' subset of the 'n' signatures who signed to release funds? I'm assuming it is because their PubKey's are provided in full in this new transaction's input?

Regardless of the details, the consensus code must be able to determine which signatures are correct in order to verify the transaction.