<p>It is, sort of, but some considerations have to be taken into account.</p>

<p>There are two ways of creating a multisig transaction: <strong>Pay-to-multisig</strong>, or a <strong>Pay-to-script-hash</strong> 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.</p>

<p><strong>Pay-to-script-hash (P2SH)</strong></p>

<p>The scripts of a 2-3 multisig encapsulated in a P2SH transaction looks like:</p>

<pre><code>ScriptSig: OP_0 [Sig 1] [Sig 2] OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG

ScriptPubKey: OP_HASH160 &lt;ScriptHash&gt; OP_EQUAL
</code></pre>

<p>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:</p>

<ul>
<li>ScriptSig: ... OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG</li>
<li>ScriptSig: ... OP_2 [PK 1][PK 3][PK 2] OP_3 OP_CHECKMULTISIG</li>
<li>ScriptSig: ... OP_2 [PK 2][PK 1][PK 3] OP_3 OP_CHECKMULTISIG</li>
<li>ScriptSig: ... OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKMULTISIG</li>
<li>ScriptSig: ... OP_2 [PK 3][PK 1][PK 2] OP_3 OP_CHECKMULTISIG</li>
<li>ScriptSig: ... OP_2 [PK 3][PK 2][PK 1] OP_3 OP_CHECKMULTISIG</li>
</ul>

<p>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.</p>

<p>e.g: </p>

<pre><code>ScriptSig: OP_0 [Sig 2] [Sig 1] OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKMULTISIG
</code></pre>

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

<p><strong>Pay-to-multisig</strong></p>

<p>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:</p>

<pre><code>ScriptSig: OP_0 [Sig 1] [Sig 2]

ScriptPubKey: OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG 
</code></pre>

<p>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.</p>

CC BY-SA 4.0
2018-12-06T14:28:42.967Z
All the `OP_CHECKSIG`s should be `OP_CHECKMULTISIG`s in this answer.
jnewbery
CC BY-SA 4.0
2018-12-06T16:20:05.603Z
You're right, I've updated the answer.
sr_gi
CC BY-SA 4.0
2017-02-21T10:14:53.573Z
2018-12-06T16:19:25.390Z
2018-12-06T16:19:25.390Z
sr_gi
<blockquote>
  <p>She sends this raw half signed transaction to Bob.</p>
</blockquote>

<p>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 <a href="https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Motivation" rel="nofollow noreferrer">the motivation section for BIP 174</a>. Specifically for your question, the PSBT should include the redeem script for any P2SH inputs.</p>

CC BY-SA 4.0
2018-12-06T14:27:46.880Z
2018-12-06T14:27:46.880Z
jnewbery
<p>step M</p>

<blockquote>
  <p>Now Alice knows both public keys but Bob does only know his public
  key.</p>
</blockquote>

<p>step N</p>

<blockquote>
  <p>Alice now creates a transaction spending the funds and signs it with
  her private key.</p>
</blockquote>

<p>It is not possible to go directly from <code>step M</code> to <code>step N</code> because nothing is to spent yet after <code>step M</code></p>

<p>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.</p>

CC BY-SA 3.0
2017-02-21T15:11:02.363Z
2017-02-21T15:11:02.363Z
amaclin
<p>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.</p>

<p>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?</p>

<p>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?</p>

<multi-signature><raw-transaction>
2of2 multisig - redeem script required
Martin
# 2of2 multisig - redeem script required

(Asked by: username_0 on 2017-02-20)

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?

**Tags:** multi-signature, raw-transaction


---

## 3 answers

### Answer by username_1 on 2017-02-21. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_2**: All the `OP_CHECKSIG`s should be `OP_CHECKMULTISIG`s in this answer.  
> **username_1**: You're right, I've updated the answer.  

---

### Answer by username_2 on 2018-12-06. Score: 0

> 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](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Motivation). Specifically for your question, the PSBT should include the redeem script for any P2SH inputs.


---

### Answer by username_3 on 2017-02-21. Score: 0

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.


---

