user9175: BIP16 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):

[signature] and {[pubkey] OP_CHECKSIG} are pushed onto the stack
OP_HASH160 hashes {[pubkey] OP_CHECKSIG}
The same hash comes from the scriptPubKey onto the stack
Consequently OP_EQUAL gives True
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?

user85: 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.

9175: <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>
 85: <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>
