<p>Yes, OP_HASH160 consumes the top stack element and replaces it with its hash.</p>

<blockquote>
  <p>So how does P2SH work, if the script is consumed after HASH160 runs?</p>
</blockquote>

<p>Here's how P2SH transactions are processed:</p>

<ol>
<li>Execute the input script (from this transaction)<br>
This is the transaction that only contains push-data-onto-stack commands.<br>
AKA scriptSig</li>
<li>Execute the output script (from the previous transaction)<br>
AKA scriptPubKey</li>
<li>Does the output script error out? If so, this transaction's invalid.</li>
<li>Does the output script end with a truthy value at the top of the stack? If not, this transaction's invalid.</li>
<li><p>Does this output script :</p>

<ol>
<li>Start with OP_HASH160,</li>
<li>have 20 bytes of data,</li>
<li>and end with OP_EQUAL?  </li>
</ol>

<p>If so, this is P2SH. <a href="https://github.com/bitcoin/bitcoin/blob/69dd8c919aa3a1b88af34265f828fe0a58a55014/src/script/script.cpp#L203" rel="nofollow noreferrer">(source)</a></p></li>
<li>If P2SH, erase the stack and run the input script again.</li>
<li>If P2SH, pop the top element of the stack off, and run it as a script. <a href="https://github.com/bitcoin/bitcoin/blob/bf7b4fc6d3bdfd9283a633da7833a5ec6fa3cd85/src/script/interpreter.cpp#L996" rel="nofollow noreferrer">(source)</a></li>
<li>If <em>that</em> script errors out, then this transactions is invalid.</li>
</ol>

CC BY-SA 3.0
2014-10-20T21:31:48.117Z
Also: good question! Any question that forces me to look the answer up is good. :)
Nick ODell
CC BY-SA 3.0
2014-10-20T22:13:34.097Z
Thanks! So it seems like there just custom code that says, if P2SH {do this extra checking, interpreting the top element of scriptSig as a script}. Is there no way to just do all this P2SH specific stuff with the OP codes that exist? Seems like no. Would it be possible to build in such an opcode, like OP_SCRIPT_DATA to signal that this is both data to be pushed and a script in itself to be run and verified?
morsecoder
CC BY-SA 3.0
2014-10-20T22:15:47.560Z
Where would I see this process you referenced shown in the source code?
morsecoder
CC BY-SA 3.0
2014-10-20T22:37:50.127Z
@StephenM347 (responding to first comment) No. The original Bitcoin spec did not allow for looping or evaluating subscripts, in order to make them easy to statically analyse. `Would it be possible to build in such an opcode, like OP_SCRIPT_DATA` Sure, but the existing push-thing-on-stack commands do the trick just fine.
Nick ODell
CC BY-SA 3.0
2014-10-20T22:39:20.330Z
@StephenM347 (second comment) Added. The embarrassing thing is that I found out that I was wrong when I looked at the source code. Oh well, fixed.
Nick ODell
CC BY-SA 3.0
2014-10-20T21:30:35.763Z
2017-01-06T23:54:53.563Z
2017-01-06T23:54:53.563Z
Nick ODell
<p>In a standard P2PKH configuration, the scripts look like: </p>

<pre><code>Pubkey script: OP_DUP OP_HASH160 &lt;PubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
Signature script: &lt;sig&gt; &lt;pubkey&gt; 
</code></pre>

<p>When redeeming P2PKH outputs, OP_DUP is done because the pubkey is used twice, once in the hash and then verifying the hashes match, and then again in verifying the signature. So, here it seems like OP_HASH160 is consuming the top stack element and replacing it with the HASH160() of what was there. </p>

<p>In P2SH transactions, the scripts look like: </p>

<pre><code>Pubkey script: OP_HASH160 &lt;Hash160(redeemScript)&gt; OP_EQUAL
Signature script: &lt;sig&gt; [sig] [sig...] &lt;redeemScript&gt;
</code></pre>

<p>When redeeming P2SH outputs, there is no OP_DUP. Won't this mean that the redeemScript will be consumed by the OP_HASH160? How can the redeemScript be executed if it was consumed by the OP_HASH160? I think I am missing something here.</p>

<script><p2sh>
Does OP_HASH160 consume the top stack element?
morsecoder
# Does OP_HASH160 consume the top stack element?

(Asked by: username_0 on 2014-10-20)

In a standard P2PKH configuration, the scripts look like: 
Pubkey script: OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
Signature script:   

When redeeming P2PKH outputs, OP_DUP is done because the pubkey is used twice, once in the hash and then verifying the hashes match, and then again in verifying the signature. So, here it seems like OP_HASH160 is consuming the top stack element and replacing it with the HASH160() of what was there. 
In P2SH transactions, the scripts look like: 
Pubkey script: OP_HASH160  OP_EQUAL
Signature script:  [sig] [sig...] 

When redeeming P2SH outputs, there is no OP_DUP. Won't this mean that the redeemScript will be consumed by the OP_HASH160? How can the redeemScript be executed if it was consumed by the OP_HASH160? I think I am missing something here.

**Tags:** script, p2sh


---

## 1 answers

### Answer by username_1 on 2014-10-20. Score: 6 | Accepted answer

Yes, OP\_HASH160 consumes the top stack element and replaces it with its hash.

> So how does P2SH work, if the script is consumed after HASH160 runs?

Here's how P2SH transactions are processed:

1. Execute the input script (from this transaction)  
   This is the transaction that only contains push-data-onto-stack commands.  
   AKA scriptSig
2. Execute the output script (from the previous transaction)  
   AKA scriptPubKey
3. Does the output script error out? If so, this transaction's invalid.
4. Does the output script end with a truthy value at the top of the stack? If not, this transaction's invalid.
5. Does this output script :

   1. Start with OP\_HASH160,
   2. have 20 bytes of data,
   3. and end with OP\_EQUAL?

   If so, this is P2SH. [(source)](https://github.com/bitcoin/bitcoin/blob/69dd8c919aa3a1b88af34265f828fe0a58a55014/src/script/script.cpp#L203)
6. If P2SH, erase the stack and run the input script again.
7. If P2SH, pop the top element of the stack off, and run it as a script. [(source)](https://github.com/bitcoin/bitcoin/blob/bf7b4fc6d3bdfd9283a633da7833a5ec6fa3cd85/src/script/interpreter.cpp#L996)
8. If *that* script errors out, then this transactions is invalid.

> **Comments:**
> **username_1**: Also: good question! Any question that forces me to look the answer up is good. :)  
> **username_0**: Thanks! So it seems like there just custom code that says, if P2SH {do this extra checking, interpreting the top element of scriptSig as a script}. Is there no way to just do all this P2SH specific stuff with the OP codes that exist? Seems like no. Would it be possible to build in such an opcode, like OP_SCRIPT_DATA to signal that this is both data to be pushed and a script in itself to be run and verified?  
> **username_0**: Where would I see this process you referenced shown in the source code?  
> **username_1**: @StephenM347 (responding to first comment) No. The original Bitcoin spec did not allow for looping or evaluating subscripts, in order to make them easy to statically analyse. `Would it be possible to build in such an opcode, like OP_SCRIPT_DATA` Sure, but the existing push-thing-on-stack commands do the trick just fine.  
> **username_1**: @StephenM347 (second comment) Added. The embarrassing thing is that I found out that I was wrong when I looked at the source code. Oh well, fixed.  

---

