<p>Ok, I found the answer after looking at some source code. For a multisig UTXO, the signature is computed using the redeem script and not the scriptPubKey from the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a>.</p>
<p>I am not sure why this is not treated uniformly given that the scriptPubKey contains the HASH160 of the redeem script and the net effect of the signature seems would be equivalent.</p>
<p>(BTW, if you know where this information is documented, add the reference here; or let me know in the comments and I will do it.)</p>
<p>The signature for the example I provide is therefore <code>3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509</code> (hex).</p>
<p>And the signed transaction becomes:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  92
    00
    48
      3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509
      01
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>To calculate the signature we use the following modified transaction where we embed the redeem script for the multisig address: OP_1 &lt;pubKey1&gt; &lt;pubKey2&gt; OP_2 OP_CHECKMULTISIG</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000
</code></pre>
<p>To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>. Its value for this example is <code>9009507119619844958975765585826516989806701453903286856798625377439958995437</code> (dec).</p>

CC BY-SA 3.0
2018-01-08T08:26:39.593Z
The demo is for a 1-of-2 multisig. When a "spending" transaction is used in a x-of-y combination, the unsigned raw tx must have several signatures in the v_in section.  The spending tx would reveal the pubkeys, which have been in the redeem script. The OP_CHECKMULTISIG would need to iterate trough the many pubkeys, and see if they fit to the signatures. With a P2PKH there wouldn't be the contents of these many pubkeys. So if you would sign a tx with P2PKH, and then be able to release the funds with a different set of keys, signature was not valid for the defined spending condition.
pebwindkraft
CC BY-SA 3.0
2018-01-09T12:37:36.630Z
@pebwindkraft thanks for sharing your insight, but I don't think that is the issue I am pointing out. If we kept the uniformity with the signing procedure of P2PKH, the spending transaction would still have a multisig scriptSig containing all the x signatures followed by the redeem script which has all the y public keys. What I mean is that, to compute these signatures, we could use the raw transaction furnished with the scriptPubKey of the UTXO, just like we did for P2PKH, instead of the redeem script. Why? 1) Because this would give the procedure an intuitive uniformity; and [...]
raugfer
CC BY-SA 3.0
2018-01-09T12:45:38.720Z
[...] 2) I believe it would have the same net effect: to compute a cryptographic signature, first we hash the data to match the word size of the ECDSA. Therefore, the redeem script is hashed with double SHA256 to compute each one of the x signatures. But note, the scriptPubKey of the UTXO already has the HASH160 of the redeem script (that is how multisig addresses are generated). So, if we use the scriptPubKey of the UTXO instead, we would be applying the double SHA256 not to the redeem script, but to a script that contains its HASH160. Wouldn't that have the same net effect?
raugfer
CC BY-SA 4.0
2018-12-21T16:36:53.170Z
You're correct that signing the p2sh `scriptPubKey` directly would achieve the same result wrt security, but by doing that we would lose the functionality of `OP_CODESEPARATOR`s in the script. The script being signed is not really the input's `scriptPubKey`, rather it's called a `scriptCode`, and if the script does not contain `CODESEPARATOR`s, then `scriptCode` is the same as the previous `scriptPubKey`. For p2sh, if we were signing the `scriptPubKey`, it would not be possible to manifest `CODESEPARATOR`'s rules on the `redeemScript` (as all we'd be signing was the hash of the full script).
arubi
CC BY-SA 3.0
2018-01-08T05:40:54.293Z
2018-01-08T05:40:54.293Z
2021-10-07T07:34:52.683Z
raugfer
<p>I am trying to figure out how to produce a valid signed transaction to
consume BTC from a multisig address.</p>
<p><strong>1) First let's look into producing a signature for an UTXO associated to a regular address:</strong></p>
<p>Assume we are creating a transaction to consume a single UTXO,
output 0 of transaction <code>1111111111111111111111111111111111111111111111111111111111111111</code> (hex),
depositing 1 BTC to address <code>147Us9aEq2PvBC5wobBJw1yEpQEbPKzssA</code>, for which the HASH160 is <code>2222222222222222222222222222222222222222</code> (hex).</p>
<p>This would be the raw transaction before signing, formatted for readability:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  00
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>Assume the UTXO is associated to the following key pair and regular address:</p>
<pre><code>L2hYQuKeAUr4hLAdDspnwm4YCcFb222REdW34WsmonEeJP5Wp4qt
02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
15Rrie5X6VgDRVwMvB63hKf8Uk5MBZEmbC
</code></pre>
<p>After signing the transaction with the private key above, we obtain ECDSA
signature <code>304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d</code> (hex) which, appended with SIGHASH_ALL byte <code>01</code> (hex), is then embedded in it using the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash" rel="nofollow noreferrer">Pay-to-PubkeyHash</a> scriptSig for regular addresses: &lt;sig&gt; &lt;pubKey&gt;.</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  6a
    47
      304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d
      01
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>In order to produce this signature, we had to sign the following modified transaction:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  19
    76
    a9
    14
      3093fd17ee01616456cc3e8d792d8d03ec31e624
    88
    ac
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000
</code></pre>
<p>Basically we patched the raw transaction with the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash" rel="nofollow noreferrer">Pay-to-PubkeyHash</a> scriptPubKey of the source UTXO: OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG. We also appended the <code>SIGHASH_ALL</code> word <code>01000000</code> (hex).</p>
<p>Note that <code>3093fd17ee01616456cc3e8d792d8d03ec31e624</code> (hex) is the HASH160 of public key <code>02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972</code>.</p>
<p>To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>.
Its value for this example is <code>11911142871849518033668783171853950819406055147191692459499720537819802969751</code> (dec).</p>
<p><strong>2) Now, for the case where the UTXO is associated to a multisig address, we need to produce a different signed transaction:</strong></p>
<p>We assume here a 1-of-2 multisig address.</p>
<p>The second key pair/address used is the following:</p>
<pre><code>Kwc7zeCyVsemqAED2cpL138hKYRTcBQgaWYHLqAPARj3K2UwjPuK
0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
1DUDqhpJS7YHsQXuchWhPJUHr2DRnHYp6X
</code></pre>
<p>Therefore the derived multisig address is <code>35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X</code>.</p>
<p>The associated raw transaction is the same. However, the signed transaction should have a different structure as we need to patch it with a <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a> scriptSig for multisig: 0 &lt;sig1&gt; OP_1 &lt;pubKey1&gt; &lt;pubKey2&gt; OP_2 OP_CHECKMULTISIG</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  91
    00
    47
      30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      01
    47
      51
      21
        02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
      21
        0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
      52
      ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>I am trying to obtain the ECDSA signature <code>30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</code> which must be computed using the first private key (its length here in <code>x</code>'s is approximate).</p>
<p>I tried to produce such signature using the raw transaction patched with the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a> scriptPubKey: OP_HASH160 &lt;scriptHash&gt; OP_EQUAL. However, the resulting signature <code>304402201264c3a19e805ff976241c20897a2c702a5fa9a3882524317ef1444b0bfebdf502207bc45af98867c9366368f2be2d3a7335bd2681c4ad58ad38224b982029fda8e5</code> (hex) seems not to be valid.</p>
<p>Below is the mentioned modified raw transaction. Note that <code>285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d</code> (hex) is the script HASH160 associated to the multisig address <code>35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X</code>:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  17
    a9
    14
      285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d
    87
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
10000000
</code></pre>
<p>Again, to facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>. Its value for this example is <code>52344238881233128299244703933491194256385056421257949759777810457555478930704</code> (dec).</p>
<p><strong>TL;DR -</strong> How to patch the raw transaction of the example above in order to produce an ECDSA signature for the associated multisig UTXO? Can you also provide a sample signed transaction and the k used in the signature calculation? <strong>OR -</strong> Where can we find this signing procedure explained in detail, textually, for multisig addresses?</p>

<multi-signature><signrawtransaction>
What do I need to sign to produce a scriptSig signature that consumes a multisig UTXO?
raugfer
# What do I need to sign to produce a scriptSig signature that consumes a multisig UTXO?

(Asked by: username_0 on 2018-01-07)

I am trying to figure out how to produce a valid signed transaction to
consume BTC from a multisig address.

**1) First let's look into producing a signature for an UTXO associated to a regular address:**

Assume we are creating a transaction to consume a single UTXO,
output 0 of transaction `1111111111111111111111111111111111111111111111111111111111111111` (hex),
depositing 1 BTC to address `147Us9aEq2PvBC5wobBJw1yEpQEbPKzssA`, for which the HASH160 is `2222222222222222222222222222222222222222` (hex).

This would be the raw transaction before signing, formatted for readability:

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  00
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

```

Assume the UTXO is associated to the following key pair and regular address:

```
L2hYQuKeAUr4hLAdDspnwm4YCcFb222REdW34WsmonEeJP5Wp4qt
02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
15Rrie5X6VgDRVwMvB63hKf8Uk5MBZEmbC

```

After signing the transaction with the private key above, we obtain ECDSA
signature `304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d` (hex) which, appended with SIGHASH\_ALL byte `01` (hex), is then embedded in it using the [Pay-to-PubkeyHash](https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash) scriptSig for regular addresses: <sig> <pubKey>.

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  6a
    47
      304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d
      01
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

```

In order to produce this signature, we had to sign the following modified transaction:

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  19
    76
    a9
    14
      3093fd17ee01616456cc3e8d792d8d03ec31e624
    88
    ac
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000

```

Basically we patched the raw transaction with the [Pay-to-PubkeyHash](https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash) scriptPubKey of the source UTXO: OP\_DUP OP\_HASH160 <pubKeyHash> OP\_EQUALVERIFY OP\_CHECKSIG. We also appended the `SIGHASH_ALL` word `01000000` (hex).

Note that `3093fd17ee01616456cc3e8d792d8d03ec31e624` (hex) is the HASH160 of public key `02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972`.

To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to [RFC6979](https://www.rfc-editor.org/rfc/rfc6979).
Its value for this example is `11911142871849518033668783171853950819406055147191692459499720537819802969751` (dec).

**2) Now, for the case where the UTXO is associated to a multisig address, we need to produce a different signed transaction:**

We assume here a 1-of-2 multisig address.

The second key pair/address used is the following:

```
Kwc7zeCyVsemqAED2cpL138hKYRTcBQgaWYHLqAPARj3K2UwjPuK
0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
1DUDqhpJS7YHsQXuchWhPJUHr2DRnHYp6X

```

Therefore the derived multisig address is `35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X`.

The associated raw transaction is the same. However, the signed transaction should have a different structure as we need to patch it with a [Pay-to-Script-Hash](https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash) scriptSig for multisig: 0 <sig1> OP\_1 <pubKey1> <pubKey2> OP\_2 OP\_CHECKMULTISIG

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  91
    00
    47
      30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      01
    47
      51
      21
        02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
      21
        0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
      52
      ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

```

I am trying to obtain the ECDSA signature `30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` which must be computed using the first private key (its length here in `x`'s is approximate).

I tried to produce such signature using the raw transaction patched with the [Pay-to-Script-Hash](https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash) scriptPubKey: OP\_HASH160 <scriptHash> OP\_EQUAL. However, the resulting signature `304402201264c3a19e805ff976241c20897a2c702a5fa9a3882524317ef1444b0bfebdf502207bc45af98867c9366368f2be2d3a7335bd2681c4ad58ad38224b982029fda8e5` (hex) seems not to be valid.

Below is the mentioned modified raw transaction. Note that `285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d` (hex) is the script HASH160 associated to the multisig address `35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X`:

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  17
    a9
    14
      285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d
    87
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
10000000

```

Again, to facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to [RFC6979](https://www.rfc-editor.org/rfc/rfc6979). Its value for this example is `52344238881233128299244703933491194256385056421257949759777810457555478930704` (dec).

**TL;DR -** How to patch the raw transaction of the example above in order to produce an ECDSA signature for the associated multisig UTXO? Can you also provide a sample signed transaction and the k used in the signature calculation? **OR -** Where can we find this signing procedure explained in detail, textually, for multisig addresses?

**Tags:** multi-signature, signrawtransaction


---

## 1 answers

### Answer by username_0 on 2018-01-08. Score: 1

Ok, I found the answer after looking at some source code. For a multisig UTXO, the signature is computed using the redeem script and not the scriptPubKey from the [Pay-to-Script-Hash](https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash).

I am not sure why this is not treated uniformly given that the scriptPubKey contains the HASH160 of the redeem script and the net effect of the signature seems would be equivalent.

(BTW, if you know where this information is documented, add the reference here; or let me know in the comments and I will do it.)

The signature for the example I provide is therefore `3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509` (hex).

And the signed transaction becomes:

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  92
    00
    48
      3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509
      01
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

```

To calculate the signature we use the following modified transaction where we embed the redeem script for the multisig address: OP\_1 <pubKey1> <pubKey2> OP\_2 OP\_CHECKMULTISIG

```
01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000

```

To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to [RFC6979](https://www.rfc-editor.org/rfc/rfc6979). Its value for this example is `9009507119619844958975765585826516989806701453903286856798625377439958995437` (dec).

> **Comments:**
> **username_1**: The demo is for a 1-of-2 multisig. When a "spending" transaction is used in a x-of-y combination, the unsigned raw tx must have several signatures in the v_in section.  The spending tx would reveal the pubkeys, which have been in the redeem script. The OP_CHECKMULTISIG would need to iterate trough the many pubkeys, and see if they fit to the signatures. With a P2PKH there wouldn't be the contents of these many pubkeys. So if you would sign a tx with P2PKH, and then be able to release the funds with a different set of keys, signature was not valid for the defined spending condition.  
> **username_0**: @username_1 thanks for sharing your insight, but I don't think that is the issue I am pointing out. If we kept the uniformity with the signing procedure of P2PKH, the spending transaction would still have a multisig scriptSig containing all the x signatures followed by the redeem script which has all the y public keys. What I mean is that, to compute these signatures, we could use the raw transaction furnished with the scriptPubKey of the UTXO, just like we did for P2PKH, instead of the redeem script. Why? 1) Because this would give the procedure an intuitive uniformity; and [...]  
> **username_0**: [...] 2) I believe it would have the same net effect: to compute a cryptographic signature, first we hash the data to match the word size of the ECDSA. Therefore, the redeem script is hashed with double SHA256 to compute each one of the x signatures. But note, the scriptPubKey of the UTXO already has the HASH160 of the redeem script (that is how multisig addresses are generated). So, if we use the scriptPubKey of the UTXO instead, we would be applying the double SHA256 not to the redeem script, but to a script that contains its HASH160. Wouldn't that have the same net effect?  
> **username_2**: You're correct that signing the p2sh `scriptPubKey` directly would achieve the same result wrt security, but by doing that we would lose the functionality of `OP_CODESEPARATOR`s in the script. The script being signed is not really the input's `scriptPubKey`, rather it's called a `scriptCode`, and if the script does not contain `CODESEPARATOR`s, then `scriptCode` is the same as the previous `scriptPubKey`. For p2sh, if we were signing the `scriptPubKey`, it would not be possible to manifest `CODESEPARATOR`'s rules on the `redeemScript` (as all we'd be signing was the hash of the full script).  

---

