<p>To answer your first question:</p>

<p>A P2SH transaction activates a special rule in Bitcoin nodes. When a Script_Publick_Key comes with this pattern:
<code>OP_HASH_160, &lt;HASH&gt;, &lt;OP_EQUAL&gt;</code>
 then the node runs the information in a different way.</p>

<p>First, it runs as it usually does. It puts the ScriptSig on top of the Script_Public_Key. The ScriptSig must follow this form:</p>

<pre><code>OP_0
&lt;Signature 1&gt;
&lt;Signature 2&gt;
...
&lt;Signature (m)&gt;
&lt;SerializedRedeemScript&gt;
</code></pre>

<p>Due to Script rules of evaluation, the first item to be evaluated is going to be the <code>&lt;SerializedRedeemScript&gt;</code>. If the hash160 of this serialized script matches the hash in the Script_Publick_Key then the first round is valid and older nodes would stop here. However, BIP0016-compliant nodes will later interpret the serialized version of the redeem script (<code>&lt;SerializedRedeemScript&gt;</code>) as actual Script commands, and the process will repeat this time with the redeem_script commands and the ScriptSig but without the <code>&lt;SerializedRedeemScript&gt;</code> since it was already consumed during the first round of validation. So, let's talk about this redeem_script.</p>

<p>The redeem script must specify how many private keys can sign a transaction (n), how many signatures are necessary to legitimately sign a transaction (m), and all the public keys that corresponds to the private keys that can sign the transaction. The form of the redeem script is as follows:</p>

<pre><code>&lt;OP_m&gt;
&lt;PublicKey 1&gt;
&lt;PublicKey 2&gt;
...
&lt; PublicKey (n)&gt;
&lt;OP_n&gt;
&lt;OP_CHECKMULTISIG&gt;
</code></pre>

<p>Since we have only consumed the <code>&lt;SerializedRedeemScript&gt;</code> in the first round of validation, then we still have our OP_0 and signatures left, and the final stack of commands, which is a combination of the redeem script and what is left from the ScripSig, will look like this:</p>

<pre><code>OP_0
&lt;Signature 1&gt;
&lt;Signature 2&gt;
...
&lt;Signature (m)&gt;
&lt;OP_m&gt;
&lt;PublicKey 1&gt;
&lt;PublicKey 2&gt;
...
&lt; PublicKey (n)&gt;
&lt;OP_n&gt;
&lt;OP_CHECKMULTISIG&gt;
</code></pre>

<p>The first OP_0 is necessary although it has no meaning at all. It is necessary because of a bug called Off-By-One bug. This was done by accident by Satoshi Nakamoto.</p>

<p>The signatures and public keys will be evaluated by the <code>&lt;OP_CHECKMULTISIG&gt;</code>. </p>

<pre><code>How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.
</code></pre>

<p>If you want to check signature by signature, then you can try to do this by first calculating the transaction hash (z) and then checking your single signature with each one of the public keys from the redeem script through OP_CHECKSIG instead of the OP_CHECKMULTISIG. If your signature is valid for a specific public key then your signature is valid. If your signature is not valid for any of the public keys then it is not valid.</p>

CC BY-SA 4.0
2020-04-03T12:52:34.820Z
Thanks for all the information. THat is a great background on how signatures are operated. I figured out that it's part of the scriptPubKey is what is being signed. I have found some tools to figure out how to generate the signature. But i still am not sure how i can verify that signature against a public key or address ? How would i go about doing that?
user3554230
CC BY-SA 4.0
2020-04-03T17:56:55.757Z
You will need to calculate z which is the transaction hash. To calculate this value, you will have to take the raw transaction's hexadecimal and replace all the inputs ScriptSigs with the redeem script + SIGHASH_ALL ("01000000" in hexadecimal). After you do this, you apply a double sha256 (also called Hash256), and that's it. You have your z. With this value you can check an individual signature and evaluate it against all the public keys from the redeem script but one by one. A signature is a pair of values (r,s). The formula you will have to evaluate is:
Oscar Serna
CC BY-SA 4.0
2020-04-03T17:58:35.637Z
(z/s)G + (r/s)PublicKey = RandomPoint
G is a point on the cryptographic curve:
    x: 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
    y: 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Oscar Serna
CC BY-SA 4.0
2020-04-03T18:02:24.490Z
The x coordinate from the resulted RandomPoint must be equal to (r) from the signature.
Oscar Serna
CC BY-SA 4.0
2020-04-03T03:49:29.787Z
2020-04-03T03:49:29.787Z
Oscar Serna
<p>I am trying to debug an issue where i believe i might have a bad signature but i am trying to figure out how to approach it.</p>

<ol>
<li><p>What is this a signature of. Private key + what (redeem script? entire raw hex?)</p></li>
<li><p>How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.</p></li>
</ol>

<p>I have 3 signatures. I want to test each signature separately to see which are bad or good. How would one approach that? I have read through many posts here but i have not found any solutions.</p>

<multi-signature><signature><p2sh>
How to Verify P2SH Signature
user3554230
# How to Verify P2SH Signature

(Asked by: username_0 on 2020-04-03)

I am trying to debug an issue where i believe i might have a bad signature but i am trying to figure out how to approach it.

1. What is this a signature of. Private key + what (redeem script? entire raw hex?)
2. How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

I have 3 signatures. I want to test each signature separately to see which are bad or good. How would one approach that? I have read through many posts here but i have not found any solutions.

**Tags:** multi-signature, signature, p2sh


---

## 1 answers

### Answer by username_1 on 2020-04-03. Score: 1 | Accepted answer

To answer your first question:

A P2SH transaction activates a special rule in Bitcoin nodes. When a Script\_Publick\_Key comes with this pattern:
`OP_HASH_160, <HASH>, <OP_EQUAL>`
then the node runs the information in a different way.

First, it runs as it usually does. It puts the ScriptSig on top of the Script\_Public\_Key. The ScriptSig must follow this form:

```
OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<SerializedRedeemScript>

```

Due to Script rules of evaluation, the first item to be evaluated is going to be the `<SerializedRedeemScript>`. If the hash160 of this serialized script matches the hash in the Script\_Publick\_Key then the first round is valid and older nodes would stop here. However, BIP0016-compliant nodes will later interpret the serialized version of the redeem script (`<SerializedRedeemScript>`) as actual Script commands, and the process will repeat this time with the redeem\_script commands and the ScriptSig but without the `<SerializedRedeemScript>` since it was already consumed during the first round of validation. So, let's talk about this redeem\_script.

The redeem script must specify how many private keys can sign a transaction (n), how many signatures are necessary to legitimately sign a transaction (m), and all the public keys that corresponds to the private keys that can sign the transaction. The form of the redeem script is as follows:

```
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

```

Since we have only consumed the `<SerializedRedeemScript>` in the first round of validation, then we still have our OP\_0 and signatures left, and the final stack of commands, which is a combination of the redeem script and what is left from the ScripSig, will look like this:

```
OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

```

The first OP\_0 is necessary although it has no meaning at all. It is necessary because of a bug called Off-By-One bug. This was done by accident by Satoshi Nakamoto.

The signatures and public keys will be evaluated by the `<OP_CHECKMULTISIG>`.

```
How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

```

If you want to check signature by signature, then you can try to do this by first calculating the transaction hash (z) and then checking your single signature with each one of the public keys from the redeem script through OP\_CHECKSIG instead of the OP\_CHECKMULTISIG. If your signature is valid for a specific public key then your signature is valid. If your signature is not valid for any of the public keys then it is not valid.

> **Comments:**
> **username_0**: Thanks for all the information. THat is a great background on how signatures are operated. I figured out that it's part of the scriptPubKey is what is being signed. I have found some tools to figure out how to generate the signature. But i still am not sure how i can verify that signature against a public key or address ? How would i go about doing that?  
> **username_1**: You will need to calculate z which is the transaction hash. To calculate this value, you will have to take the raw transaction's hexadecimal and replace all the inputs ScriptSigs with the redeem script + SIGHASH_ALL ("01000000" in hexadecimal). After you do this, you apply a double sha256 (also called Hash256), and that's it. You have your z. With this value you can check an individual signature and evaluate it against all the public keys from the redeem script but one by one. A signature is a pair of values (r,s). The formula you will have to evaluate is:  
> **username_1**: (z/s)G + (r/s)PublicKey = RandomPoint G is a point on the cryptographic curve:     x: 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798     y: 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8  
> **username_1**: The x coordinate from the resulted RandomPoint must be equal to (r) from the signature.  

---

