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

[No_2]

For a P2SH transaction does the script specify how many signatures are required for the 'n' of m-of-n?

For example, if 6 people agree to set up a 6-of-6 P2SH transaction and sign it in sequence, where Person A is the first to sign and Person F is the last to sign. Does Person A who creates the P2SH script specify in the script that 6 People have to sign?

I.e. could Person E sign and broadcast the P2SH transaction, missing out Person F and making the transaction 5-of-5?

[1713297211]

1713297211

[1713297211]

1713297211

[1713297211]

1713297211

[1713297211]

1713297211

[1713297211]

1713297211

[1713297211]

1713297211

[DannyHamilton]

When sending to an "m-of-n" address using P2SH, you don't need the signatures from the private keys of ANY of the public keys that are in the script.  You ONLY need the signatures of the private keys that are associated with the funds that are being spent.

The P2SH redeem script would provide a specific list of exactly which private keys are authorized in the future to spend the output that is being created in the transaction (identified by their public keys).  It would also provide an exact quantity of signatures that are required.

Therefore, the person that creates the transaction that funds the P2SH address has full control over which private keys (and how many) are needed in the future to spend the bitcoins that are received at that address.

Example:

I create a transaction funding a P2SH.
In creating the transaction, I define 4 authorized signatories.
In creating the transaction, I define a requirement that 3 of those signatures be present.
I then sign my transaction and broadcast it. (see, I'm the ONLY one that needs to sign this, since I'm sending funds that I personally have control over)
The transaction is eventually mined and added to the blockchain.

Now the only way that those funds can be used to fund a future transaction is if signatures are provided by 3 of the 4 required signers.

If 2 of the signers try to create their own transaction that spends the output that I created, then their transaction will be rejected as invalid unless they can get one of the remaining 2 signers to sign their transaction.

[No_2]

Thanks for this.

I'm talking more specifically in a scenario where a number of parties are collating funds to a single P2SH address.

To give another example two people are trusting 4 separate escrow to look after their funds, so the first person creates a Transaction with 2 inputs (one for each person depositing the money) and one P2SH output. The first person then signs the first input and the P2SH output script and passes it to the second person who does the same. The second person then passes it to the first escrow.

In this scenario we must assume that we cannot fully trust any of the escrow who need  to sign in sequence. Therefore what is to stop the any of these escrow from signing the transaction's output P2SH and then broadcasting it early excluding the other escrow from signing? E.g. if the first escrow broadcasts then could they create an 3-of-3 instead of the intended 6-of-6?

I'm currently under the impression this would not be possible because it is enforced by the script which was created by the first person as 6-of-6?

I'm not sure if this is a suitable use-case however as I understand P2SH requires proof to spend the output, but I'm not sure about enforcing that the output validates as true before it is mined to a block.

[dabura667]

a P2SH is exactly that: PAY TO SCRIPT HASH.

In other words, the script is set in stone the second you fund it.

If you don't fund it... there's nothing to sign.



So in other words, no, you can not do the situation you described.

The flow works like this:

I make a P2SH multisig that is m of n.

I gather the pubkeys of the other n - 1 participants, and I use their pubkeys along with mine to generate the script, and hash it.

I then get a P2SH address. (which is a hash, so unchangeable once finalized)

Then I send bitcoins to that address. At this point the n, the m, and each individual pubkey are set in stone. I can not change the pubkeys out with other ones, I can not change the number of signs required... because the hash already has bitcoins sent to it...

the script that you are hashing has m, n, each pubkey, and the checkmultisig op code in it.

[No_2]

Thanks,

So to rectify the last example I gave the first and second person would get the 4 escrow to sign the output P2SH script first. Then the first person would sign the first input and P2SH output, then then second person would sign the second input and P2SH output and broadcast the TX.

That way there is no risk of the escrow broadcasting the TX early. (Edit: and rendering the funds un-spendable)

Have I understood this correctly now?

[DeathAndTaxes]

I think (based on your wording) you may be confused as to when the P2SH script is evaluated.  The script which is hashed is the redeemScript because it is only evaluated when the funds are spent not received from/to the P2SH address. 

The requirements for spending are set by the output being spent.  If you are sending funds to my P2SH address it is your keys not mine which are used in the signing.   This is no different than a single key scenario.  The difference between P2SH and P2PkH only occurs when funds are being spent 'from' the address.  Sending funds to the address is identical.  In both cases the recipient isn't involved at all providing the address. 

The trustees in your example wouldn't sign the funding transaction at all.  This is no different than for P2PkH.  If I give you my address I don't need to sign the transaction in order for you to be able to send coins to me.

An example might help:
Alice, Bob, and Charlie have an situation where they need multi-user control to spend (not receive) funds.   They create a script S.  This is the redeemScript and they will need to retain a copy or be able to reproduce it later from some deterministic method.  When HASH256 is applied to this script it produces a hash Hs.  When encoded in Base58 this produced an address As to users who wish to send funds to them. 

An example of the redeemScript

Code:

2 <AlicePubKey> <BobPubKey> <CharliePubKey> 3 OP_CHECKMULTISIG

In this script m is 2 and n is 3.  As you can see n is somewhat redundant because there are three public keys there.  If you had an n value of anything but three in this scenario the script would be invalid.   The m=2 means that to spend coins received by As the txn will need to be signed by exactly two of the three keys specified.


Now Joe and Sam wish to send funds to the organization of Alice, Bob, and Charlie.  Joe and Sam create a transaction (or seperate transactions) sending funds to address As.  The PkScript in the output of that txn contains a short script which looks something like this.

Code:

OP_HASH160 <Hs> OP_EQUAL

Joe's wallet takes the address given (As) decodes and due to the 'version' knows the output is a ScriptHash (Hs) and creates this specific script as the PkScript of the txn output.  The output is now locked to a script (S) which will be provided later when the funds are spent.

The only signatures in this 'funding transaction' are Joe and/or Sam.  Now later as an unrelated txn funds need to be spent from As.  The input of that txn will reference one or more unspent outputs (possibly Joe or Sam's prior txns).  The ScriptSig in the input will require both the full redeemScript (to verify it does hash to Hs) and two valid signatures produced from the set of Alice, Bob, and Charlie's private keys.

[DeathAndTaxes]

So to rectify the last example I gave the first and second person would get the 4 escrow to sign the output P2SH script first.

No none of the escrows would sign the txn sending funds TO the P2SH address.

It really is no different than single keys.  I give you a single key address.  You create a txn sending 1 BTC to that address.  Who signs the txn?
a) you
b) me
c) you and me

I give you a P2SH address.  You create a txn sending 1 BTC to that address.  Who signs the txn?
a) you
b) me
c) you and me

Make sense?

[No_2]

Thanks for taking the time to explain this.

So talking specifically about P2SH if I have the public keys for all the signatories I need (say 3 public keys) this is all the information I need to generate the P2SH address, where I can specify m <= 3 and n as >= 1 but <=3?

[DannyHamilton]

Thanks for taking the time to explain this.

So talking specifically about P2SH if I have the public keys for all the signatories I need (say 3 public keys) this is all the information I need to generate the P2SH address, where I can specify m <= 3 and n as >= 1 but <=3?

Yes.  I already explained this:

- snip -
Example:

I create a transaction funding a P2SH.
In creating the transaction, I define 4 authorized signatories.
In creating the transaction, I define a requirement that 3 of those signatures be present.
I then sign my transaction and broadcast it. (see, I'm the ONLY one that needs to sign this, since I'm sending funds that I personally have control over)
The transaction is eventually mined and added to the blockchain.
- snip -

My example works the same if there are 2 people funding an address that will eventually require 5 of 6 signatures.

Example:

• Each of the two people funding the P2SH provide the unspent outputs that they will be using to fund the transaction.
• One person with access to all six of the public keys creates a transaction funding a P2SH. (Only one person needs to create this, more can participate if desired, but later anyone funding the transaction should review it before signing it to be sure that it properly implements what they agreed to).
• In creating the transaction, they define the 6 authorized signatories for spending the newly created output in the future.
• In creating the transaction, they define the requirement that 5 of those signatures be present.
• Each of the two people that are funding the P2SH each review and sign the transaction. (See, only those FUNDING the transaction need to sign it.  Not those that are receiving it).
  
• The transaction is broadcast
• The transaction is eventually added to the blockchain

Now the only way that those funds can be used to fund a future transaction is if signatures are provided by 5 of the 6 required signers.

[DeathAndTaxes]

So talking specifically about P2SH if I have the public keys for all the signatories I need (say 3 public keys) this is all the information I need to generate the P2SH address, where I can specify m <= 3 and n as >= 1 but <=3?

Yes.  Also m <= n which isn't clear from the way you worded it.  The other gotcha is many users think of their address as their key but the address decodes to the pubkeyhash* not the pubkey.    

* Now that v.10 makes most redeem scripts standard it would be possible to make a multisig script using pubkeyhashes.  That would make it a lot easier to setup escrow and payment channels because users could just provide their address.  The bad news is no standard client would understand how to sign that transaction right now but maybe someday as it could be changed with client updates.  No fork of the protocol is necessary.

[No_2]

Yes.  I already explained this:

- snip -
Example:

I create a transaction funding a P2SH.
In creating the transaction, I define 4 authorized signatories.
In creating the transaction, I define a requirement that 3 of those signatures be present.
I then sign my transaction and broadcast it. (see, I'm the ONLY one that needs to sign this, since I'm sending funds that I personally have control over)
The transaction is eventually mined and added to the blockchain.
- snip -

My example works the same if there are 2 people funding an address that will eventually require 5 of 6 signatures.
...

Ah, I did not quiet understand. So in the above example you are already assuming I have the public keys. If so I now get this.

Each of the two people funding the P2SH provide the unspent outputs that they will be using to fund the transaction

By 'provide' here do you mean that they provide separate signatures to 'spend' each of the two outputs to this new transaction?

Each of the two people that are funding the P2SH each review and sign the transaction. (See, only those FUNDING the transaction need to sign it. Not those that are receiving it).

Ok, so they would both need to see the script and verify the P2SH address which is the output of the new transaction is from that script and those public keys. I assume they would do this before signing their respective inputs? Where one would have to sign, then pass the transaction on to the other to then sign the second input and broadcast? Hope I have this correct now?

[No_2]

So talking specifically about P2SH if I have the public keys for all the signatories I need (say 3 public keys) this is all the information I need to generate the P2SH address, where I can specify m <= 3 and n as >= 1 but <=3?

Yes.  Also m <= n which isn't clear from the way you worded it.  The other gotcha is many users think of their address as their key but the address decodes to the pubkeyhash not the pubkey.     

It is possible to make a redeemScript which validates signatures form multiple pubkeyhashes instead of pubkeys.  The bad news is no standard client would understand how to sign that transaction.  The good news is that this could be changed by just client updates it wouldn't require a fork of the protocol.

Thanks for all the help here.

I'm going to have a think and re-word an attempt at getting this correct so I can confirm I understand it. It may be tomorrow though.

[DannyHamilton]

- snip -

Each of the two people funding the P2SH provide the unspent outputs that they will be using to fund the transaction

By 'provide' here do you mean that they provide separate signatures to 'spend' each of the two outputs to this new transaction?
- snip -

No. No signatures at this point.  The signatures aren't provided until after the transaction is completely built.

What I mean is that the person building the transaction will need to know exactly which outputs are being used to fund the transaction.  They'll need a list of transactionID and vout values that they will use as inputs in this transaction.

[No_2]

So to confirm I've got the logic of this and the dependencies correct:

Scriptsig is the signature which unlocks Scriptpubkey where Scriptpubkey is the output of a given transaction which must be satisfied to be spendable to a new output.

Am I right in thinking that Scriptsig is the private key signing over the (entire?) transaction which can then be verified by the public key?

And the public key can be verified as it matches a hash of the previous transaction's output (the Bitcoin address)?

Both the public key and Scriptsig are sent with the new transaction.

Therefore the above dependencies prove the person who broadcast the new transaction has possession of the private key for the output of the previous transaction.

[DannyHamilton]

There are some implementation details that differ slightly from your description, but at a general level it sounds like you've got a good understanding.

[No_2]

Thanks, can I also check I've got this right:

When the transaction is stored on the blockchain, the Scriptpubkey script which contains the address is stored as the conditions to satisfy to use the output.

The Scriptsig and public key are not stored on the blockchain.

Scriptpubkey is an actual script, stored on the blockchain that is the condition required (to evaluate as 'True') to be able to spend that output to another transaction's output(s), with one script per output.

[DannyHamilton]

Thanks, can I also check I've got this right:

When the transaction is stored on the blockchain, the Scriptpubkey script which contains the address is stored as the conditions to satisfy to use the output.

Scriptpubkey is an actual script, stored on the blockchain that is the condition required (to evaluate as 'True') to be able to spend that output to another transaction's output(s), with one script per output.

Correct.

Note regarding the underlined part:

The ScriptPubKey typically does not "contain the address".  An address is a user interface feature used by wallets to collect and verify the information necessary for building the ScriptPubKey.  As such, a bitcoin address typically includes an encoded version number and checksum.  When building the actual ScriptPubKey, the wallet decodes the address, extracts from it the public key hash, verifies the checksum, and uses the version number to identify exactly what type of script to create.  The ScriptPubKey then typically includes the public key hashes, and not the bitcoin addresses. Also, it is possible for an output to not require a signature at all.  In that case, there would not be a public key hash, but rather there would be a script that would accept some input and evaluate to either 'True' or 'False' depending on that input.

The Scriptsig and public key are not stored on the blockchain.

This is not correct.  When you reference an unspent output from a previous transaction as an input into a new transaction, the Scriptsig and public key are included in that new transaction's input and that input is stored on the blokchain as part of the new transaction.

[hhanh00]

You may be over thinking this. First of all, P2SH and multi-sig are two orthogonal things. You can have a P2SH without multi-sig, a multi-sig without P2SH, etc.

So let's start with a non P2SH multi-sig. Since it's a normal tx, you have a pubscript and a sigscript. Put together, they should evaluate to true.
A multi-sig pubscript looks like <M> <pubkey1> ... <pubkeyN>. Whoever funds the output decides what the public keys are and how many are needed.
To spend it, M signatures must be provided in the redeem script.

This is all good but inconvenient because to add more money to the pool, i.e. to create another output that has the same spending requirements, you have to copy the multi-sig pubscript. Contrast this with the case of a pay-to-pubhash where the address is sufficient. From the address, the wallet app can calculate the pub hash and form the corresponding pay-to-pubhash script.

P2SH is the chosen solution to this issue (Other solutions were proposed). To generalize, we can consider a broader case where the script is more complicated. Basically, P2SH are not limited to multi-sig even though these are the most common usage.

Problem: We have a pubscript X. People should be able to send money with the same redeeming conditions without having X. The secrecy of X is not the main point, but having a super long 'address' that would decode to X is.

With P2SH, X is hashed like the pubkey is hashed for a classic pay-to-pubhash script. To differentiate from the later, another address version is used.
That makes the P2SH addresses stand out because they start with '3' instead of '1'.

People can send money to the P2SH address without knowing X. Essentially, they are sending to the hash of X, i.e. the hash of the script. Hence, the name: Pay to Script Hash.

When someone wants to redeem the money, it gets a bit more complicated for him than in the normal case.
He has to provide the redeem script (like in the normal case) *and* he has to provide X.
First, the bitcoin node checks that the hash of X corresponds to the hash given in the P2SH. Then it further checks that the redeem script is correct in respect to X.

PS:
A P2SH script looks like OP_HASH160 <hash> OP_EQUAL. The validation code recognizes this particular script and executes the two step validation. A client that is not aware of P2SH would only do the first step.

[No_2]

...

The Scriptsig and public key are not stored on the blockchain.

This is not correct.  When you reference an unspent output from a previous transaction as an input into a new transaction, the Scriptsig and public key are included in that new transaction's input and that input is stored on the blokchain as part of the new transaction.

Ah, I didn't realise that. Is the public key stored 'as is' or is it a shortened or hashed version of it the public key?

If it's not shortened is it provided in full for all to see that the new transaction spending that output is valid?

[No_2]

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?

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?

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.