2of2 multisig - redeem script required

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?

Answers 3

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:

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_CHECKSIG

ScriptSig: ... OP_2 [PK 1][PK 3][PK 2] OP_3 OP_CHECKSIG

ScriptSig: ... OP_2 [PK 2][PK 1][PK 3] OP_3 OP_CHECKSIG

ScriptSig: ... OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKSIG

ScriptSig: ... OP_2 [PK 3][PK 1][PK 2] OP_3 OP_CHECKSIG

ScriptSig: ... OP_2 [PK 3][PK 2][PK 1] OP_3 OP_CHECKSIG

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.

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.

sr-gi February 21, 2017 10:14 AM

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.

amaclin February 21, 2017 15:11 PM

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.