2of2 multisig - redeem script required

Question

Normally somebody who signs a multisig transaction also needs the redeem script or all the public keys used for the creation of the redeem script, alongside their own private key.

No I was thinking, is this also required for a 2of2 multisig address. Let's say the 2 parties are Alice and Bob. Alice and Bob both generate a keypair. Bob sends his public key to Alice and she creates the redeem script. Now Alice knows both public keys but Bob does only know his public key. Alice now creates a transaction spending the funds and signs it with her private key. She sends this raw half signed transaction to Bob. So far so normal. But normally here Bob needs the redeem script or both public keys to generate the redeem script himself. I was wondering now: When signing the transaction Alice adds her signature to the transaction and also her public key so the signature can be verified. So Bob could extract Alice's public key from the raw transaction he just received and use that to generate the redeem script himself?

So my question is: Is this true? And if it is, does that mean that no matter if it is 2of2 or 4of4 the last signer can always recreate the redeem script from the received raw transaction?

Answer 1

It is, sort of, but some considerations have to be taken into account.

There are two ways of creating a multisig transaction: Pay-to-multisig, or a Pay-to-script-hash encapsulating a Pay-to-multisig. For how you are asking the question I guess that you are referring to the latter. However, I will give you both answers just in case.

Pay-to-script-hash (P2SH)

The scripts of a 2-3 multisig encapsulated in a P2SH transaction looks like:

ScriptSig: OP_0 [Sig 1] [Sig 2] OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG

ScriptPubKey: OP_HASH160 <ScriptHash> OP_EQUAL

As you mentioned, Bob will be able to recreate the script since the ScriptPubKey only required the hash of the generated scriptSig, and he will have all the information. However, order matters. In this case (a 2-3 multisig) Alice could have build the script in six different ways:

• ScriptSig: ... OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG
• ScriptSig: ... OP_2 [PK 1][PK 3][PK 2] OP_3 OP_CHECKMULTISIG
• ScriptSig: ... OP_2 [PK 2][PK 1][PK 3] OP_3 OP_CHECKMULTISIG
• ScriptSig: ... OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKMULTISIG
• ScriptSig: ... OP_2 [PK 3][PK 1][PK 2] OP_3 OP_CHECKMULTISIG
• ScriptSig: ... OP_2 [PK 3][PK 2][PK 1] OP_3 OP_CHECKMULTISIG

This have two consequences, the most straightforward is that if the script is not build in the same way, the hash will be different. Moreover, the order in which the keys are provided indicates how the signatures should be provided, that is, signatures and keys have to be provided in the same order.

e.g:

ScriptSig: OP_0 [Sig 2] [Sig 1] OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKMULTISIG

Then, in a n-m multisig, Alice will have n! ways of arranging the Public keys. If not provided in the right order, the evaluation of the script will fail, making the transaction invalid.

Pay-to-multisig

In the case of Pay-to-multisig, the solution is way more straightforward due the information that each script stores. Using the same 2-3 multisig example, the resulting scripts will be:

ScriptSig: OP_0 [Sig 1] [Sig 2]

ScriptPubKey: OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG 

In this case, not just the latter, but every party involved will know how to build the ScriptSig, since how the ScripPubKey was build is accessible from the previous transaction.

Answer 2

step M

Now Alice knows both public keys but Bob does only know his public key.

step N

Alice now creates a transaction spending the funds and signs it with her private key.

It is not possible to go directly from step M to step N because nothing is to spent yet after step M

First of all Alice should create 2-of-2 multisig address and somebody should fund it. After funding they must create and sign the spending transaction.

Answer 3

She sends this raw half signed transaction to Bob.

Sending around unsigned or partially signed transactions has always been tricky and implementation specific. This is the problem that Partially Signed Bitcoin Transactions was designed to solve. See the motivation section for BIP 174. Specifically for your question, the PSBT should include the redeem script for any P2SH inputs.