<p>I've been hunting for this information myself, and had to dig to the bitcoin source code to find the answer - couldn't find it anywhere else.</p>

<p>There is a hardcoded logic in bitcoin for P2SH validation:</p>

<p>The stack is backed up between the steps 2 and 3 (generally - between scriptSig and scriptPubKey execution).</p>

<p>After both scripts are executed and verified, the stack is restored from the earlier backup, the redeem script is popped from the stack, deserialized, executed and verified. This is done by internal bitcoin code, not by any script.</p>

<p>Corresponding source code:
<a href="https://github.com/bitcoin/bitcoin/blob/6fef85bfa3cd7f76e83b8b57f9e4acd63eb664ec/src/script/interpreter.cpp" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/6fef85bfa3cd7f76e83b8b57f9e4acd63eb664ec/src/script/interpreter.cpp</a></p>

<p>Stack is backed up at 1493, and restored at 1529, where all the magic begins. </p>

CC BY-SA 4.0
2016-10-06T15:12:33.603Z
2019-12-20T20:53:04.010Z
2019-12-20T20:53:04.010Z
Jan Koriťák
<p>Combining the spending transaction scriptSig and funding transaction scriptPubKey, we get:</p>

<pre><code>&lt;OP_0&gt; &lt;sig A&gt; &lt;sig C&gt; &lt;redeemScript&gt; &lt;OP_HASH160&gt; &lt;redeemScriptHash&gt; &lt;OP_EQUAL&gt;
</code></pre>

<p>Stepping through this script:</p>

<p>1)OP_0 and the two signatures are added to the stack, kept for later.</p>

<p>2)The redeemScript is added to the stack.</p>

<p>3)OP_HASH160 hashes our redeemScript.</p>

<p>4)redeemScriptHash is added to the stack.</p>

<p>5)OP_EQUAL will compare OP_HASH160(redeemScript) and redeemScriptHash and check for equality. This confirms that our spending transaction is providing the correct redeemScript.</p>

<p>6)Now our redeemScript can be evaluated:</p>

<pre><code>&lt;OP_2&gt; &lt;A pubkey&gt; &lt;B pubkey&gt; &lt;C pubkey&gt; &lt;OP_3&gt; &lt;OP_CHECKMULTISIG&gt;
</code></pre>

<p>7)OP_CHECKMULTISIG will look at the 3 public keys and 2 signatures in the stack, and compare them one by one. As stated earlier, the order of signatures matters here and must match the order that the public keys were provided in.</p>

<p>8)OP_0 is included only to deal with an off-by-one error in Bitcoin Core when using OP_CHECKMULTISIG.</p>

<p>i read several answers related to this topic and i read also the BIP16 but i still can not understand how after validation with <code>&lt;OP_EQUAL&gt;</code>of <code>&lt;redeemScript&gt;</code> calculated with <code>&lt;OP_HASH160&gt;</code> and <code>&lt;redeemScriptHash&gt;</code> the script continues with the validation of <code>&lt;sig A&gt; &lt;sig C&gt;</code></p>

<p>After the procedure which i have already described the only portions left in the stack are : <code>&lt;OP_0&gt; &lt;sig A&gt; &lt;sig C&gt;</code> How these signatures will be verified since the fact that <code>&lt;redeemScript&gt;</code> is poped out of the stack?</p>

<p><strong>My question in other words has to do with step 6.</strong>
<em>Now our redeemScript can be evaluated:</em> how since it has been removed from the stack...</p>

<transactions><p2sh>
Pay to Script Hash Execution
gtopal
# Pay to Script Hash Execution

(Asked by: username_0 on 2016-01-22)

Combining the spending transaction scriptSig and funding transaction scriptPubKey, we get:

```
<OP_0> <sig A> <sig C> <redeemScript> <OP_HASH160> <redeemScriptHash> <OP_EQUAL>

```

Stepping through this script:

1)OP\_0 and the two signatures are added to the stack, kept for later.

2)The redeemScript is added to the stack.

3)OP\_HASH160 hashes our redeemScript.

4)redeemScriptHash is added to the stack.

5)OP\_EQUAL will compare OP\_HASH160(redeemScript) and redeemScriptHash and check for equality. This confirms that our spending transaction is providing the correct redeemScript.

6)Now our redeemScript can be evaluated:

```
<OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> <OP_CHECKMULTISIG>

```

7)OP\_CHECKMULTISIG will look at the 3 public keys and 2 signatures in the stack, and compare them one by one. As stated earlier, the order of signatures matters here and must match the order that the public keys were provided in.

8)OP\_0 is included only to deal with an off-by-one error in Bitcoin Core when using OP\_CHECKMULTISIG.

i read several answers related to this topic and i read also the BIP16 but i still can not understand how after validation with `<OP_EQUAL>`of `<redeemScript>` calculated with `<OP_HASH160>` and `<redeemScriptHash>` the script continues with the validation of `<sig A> <sig C>`

After the procedure which i have already described the only portions left in the stack are : `<OP_0> <sig A> <sig C>` How these signatures will be verified since the fact that `<redeemScript>` is poped out of the stack?

**My question in other words has to do with step 6.**
*Now our redeemScript can be evaluated:* how since it has been removed from the stack...

**Tags:** transactions, p2sh


---

## 1 answers

### Answer by username_1 on 2016-10-06. Score: 7

I've been hunting for this information myself, and had to dig to the bitcoin source code to find the answer - couldn't find it anywhere else.

There is a hardcoded logic in bitcoin for P2SH validation:

The stack is backed up between the steps 2 and 3 (generally - between scriptSig and scriptPubKey execution).

After both scripts are executed and verified, the stack is restored from the earlier backup, the redeem script is popped from the stack, deserialized, executed and verified. This is done by internal bitcoin code, not by any script.

Corresponding source code:
<https://github.com/bitcoin/bitcoin/blob/6fef85bfa3cd7f76e83b8b57f9e4acd63eb664ec/src/script/interpreter.cpp>

Stack is backed up at 1493, and restored at 1529, where all the magic begins.


---

