<p>You're correct so far, you just stopped before you were finished. As BIP16 says, it "defines additional validation rules that apply only to the new transactions" -- specifically, "{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey."</p>

<p>So:</p>

<p>1) The script is popped off the stack, leaving only <code>[signature]</code> on the stack.</p>

<p>2) The deserialized script is added, leaving <code>[signature] [pubkey] OP_CHECKSIG</code>.</p>

<p>2) The transaction is validated again, that is, a normal signature verification occurs against the specified public key.</p>

CC BY-SA 3.0
2015-08-19T14:05:21.430Z
i'd like a more comprehensive walkthrough, or a link to one. i still don't get it.
mulllhausen
CC BY-SA 3.0
2016-11-18T12:50:42.293Z
This doesn't really answer the question at all as to how the pushed script bytes get executed. I assume BIP16 defies somewhere in it's complex language a definition for how the network identifies a "serialized script", since it is just data. Why would signatures, public keys, etc not be attempted to be interpreted as scripts as well given this definition?
Earlz
CC BY-SA 3.0
2013-12-27T14:05:25.183Z
2013-12-27T14:05:25.183Z
David Schwartz
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">BIP16</a> gives the following example to explain "Pay to Script Hash":</p>

<pre><code>scriptSig:    [signature] {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
</code></pre>

<p>But I don't get what's happening here. I've tried executing the script on paper (and assumed the parts in squared/curly brackets are treated as constants):</p>

<ol>
<li><code>[signature]</code> and <code>{[pubkey] OP_CHECKSIG}</code> are pushed onto the stack</li>
<li><code>OP_HASH160</code> hashes <code>{[pubkey] OP_CHECKSIG}</code></li>
<li>The same hash comes from the <code>scriptPubKey</code> onto the stack</li>
<li>Consequently <code>OP_EQUAL</code> gives <code>True</code></li>
<li>The <code>[signature]</code> is not checked at all!</li>
</ol>

<p>If the <code>{[pubkey] OP_CHECKSIG}</code> is executed, the scriptSig would only give <code>True</code>, which makes even less sense.</p>

<p>To frame a clear question: How do "Pay to Script Hash" scripts work, especially this example case?</p>

<script><p2sh>
How do "Pay to Script Hash" transactions work?
jnnk
# How do "Pay to Script Hash" transactions work?

(Asked by: username_0 on 2013-12-27)

[BIP16](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) gives the following example to explain "Pay to Script Hash":

```
scriptSig:    [signature] {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

```

But I don't get what's happening here. I've tried executing the script on paper (and assumed the parts in squared/curly brackets are treated as constants):

1. `[signature]` and `{[pubkey] OP_CHECKSIG}` are pushed onto the stack
2. `OP_HASH160` hashes `{[pubkey] OP_CHECKSIG}`
3. The same hash comes from the `scriptPubKey` onto the stack
4. Consequently `OP_EQUAL` gives `True`
5. The `[signature]` is not checked at all!

If the `{[pubkey] OP_CHECKSIG}` is executed, the scriptSig would only give `True`, which makes even less sense.

To frame a clear question: How do "Pay to Script Hash" scripts work, especially this example case?

**Tags:** script, p2sh


---

## 1 answers

### Answer by username_1 on 2013-12-27. Score: 8 | Accepted answer

You're correct so far, you just stopped before you were finished. As BIP16 says, it "defines additional validation rules that apply only to the new transactions" -- specifically, "{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey."

So:

1) The script is popped off the stack, leaving only `[signature]` on the stack.

2) The deserialized script is added, leaving `[signature] [pubkey] OP_CHECKSIG`.

2) The transaction is validated again, that is, a normal signature verification occurs against the specified public key.

> **Comments:**
> **username_2**: i'd like a more comprehensive walkthrough, or a link to one. i still don't get it.  
> **username_3**: This doesn't really answer the question at all as to how the pushed script bytes get executed. I assume BIP16 defies somewhere in it's complex language a definition for how the network identifies a "serialized script", since it is just data. Why would signatures, public keys, etc not be attempted to be interpreted as scripts as well given this definition?  

---

