<p>I suspect you may have a misconception over how the script is executed, and what the stack contains during execution.</p>

<p>First, remember that the full script is created by adding the two partial scripts together in this order: scriptSig + scriptPubKey.</p>

<p>Each element of the full script is either a value which is pushed onto the stack, or an operation which examines and/or manipulates the stack.</p>

<p>A valid script is executed left to right until either the end is reached, or an operation indicates a failure. If the script completes without any operation indicating an early failure, then the top of the stack (alone) indicates the failure/success. As user <a href="https://bitcoin.stackexchange.com/users/24925/bitcoin">Bitcoin</a> has already said, any non-zero value is considered a success, and any items beneath the stack's top are (currently) ignored.</p>

<p>If someone tried to create a tx whose scriptSig was simply OP_TRUE, the entire script would typically look like:</p>

<pre><code>OP_TRUE OP_DUP OP_HASH160 &lt;PubkeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>The first script step pushes <code>1</code> onto the stack, next it's duplicated, and then the duplicate on top is hashed. After executing these first three script instructions, you'd have:</p>

<pre><code>Stack:
HASH160(1)  &lt;-- stack top
1

Remaining (unexecuted) script: &lt;PubkeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>Next <code>&lt;PubkeyHash&gt;</code> is pushed onto the stack, and then the two top elements (<code>&lt;PubkeyHash&gt;</code> and <code>HASH160(1)</code>) are compared, which causes the script to fail.</p>

<p>In short, because scriptPubKey is added <em>after</em> scriptSig, scriptSig has no way to "override" what scriptPubKey tells the script interpreter to eventually execute. (There's no such instruction as "exit immediately with success" that scriptSig could include.)</p>

<p>Finally, user <a href="https://bitcoin.stackexchange.com/users/24925/bitcoin">Bitcoin</a> also mentioned that BIP62 changes the "in the end, ignore everything but the top of the stack" rule. This will probably be true one day (and would make no difference in this example anyways), however as of today the rules in BIP62 haven't yet been implemented (except for the one also mentioned in BIP66).</p>

CC BY-SA 3.0
2015-04-25T21:27:43.350Z
2015-04-25T21:33:12.083Z
2017-04-13T12:47:32.940Z
Christopher Gurnee
<p>Contrary to the book Mastering Bitcoin, there is no boolean value of "True" in Bitcoin Script. An executed transaction script is valid when the top item remaining in the stack at the conclusion of execution is non-zero. To combat transaction malleability <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki" rel="noreferrer">BIP62</a> (transaction version 3) also introduces the additional validity requirement that the stack must contain no additional data elements, only the single non-zero value.</p>

CC BY-SA 3.0
2015-04-25T20:06:34.723Z
2015-06-30T07:24:33.493Z
2015-06-30T07:24:33.493Z
Claris
<p>If at the middle of the execution of scriptSig + scriptPubKey we get the value 'True', while there are remaining values or operators in the stack, is the transaction valid? Or should the stack be empty + top result is 'True' ?
I believe it is not because someone can just send unlocking script with the 'OP_TRUE' and cause any UTXO to be unlocked. </p>

<script><transaction-verification>
Does value 'True' at the middle of stack is valid transaction?
Haddar Macdasi
# Does value 'True' at the middle of stack is valid transaction?

(Asked by: username_0 on 2015-04-25)

If at the middle of the execution of scriptSig + scriptPubKey we get the value 'True', while there are remaining values or operators in the stack, is the transaction valid? Or should the stack be empty + top result is 'True' ?
I believe it is not because someone can just send unlocking script with the 'OP\_TRUE' and cause any UTXO to be unlocked.

**Tags:** script, transaction-verification


---

## 2 answers

### Answer by username_2 on 2015-04-25. Score: 7 | Accepted answer

Contrary to the book Mastering Bitcoin, there is no boolean value of "True" in Bitcoin Script. An executed transaction script is valid when the top item remaining in the stack at the conclusion of execution is non-zero. To combat transaction malleability [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) (transaction version 3) also introduces the additional validity requirement that the stack must contain no additional data elements, only the single non-zero value.


---

### Answer by username_1 on 2015-04-25. Score: 3

I suspect you may have a misconception over how the script is executed, and what the stack contains during execution.

First, remember that the full script is created by adding the two partial scripts together in this order: scriptSig + scriptPubKey.

Each element of the full script is either a value which is pushed onto the stack, or an operation which examines and/or manipulates the stack.

A valid script is executed left to right until either the end is reached, or an operation indicates a failure. If the script completes without any operation indicating an early failure, then the top of the stack (alone) indicates the failure/success. As user [Bitcoin](https://bitcoin.stackexchange.com/users/24925/bitcoin) has already said, any non-zero value is considered a success, and any items beneath the stack's top are (currently) ignored.

If someone tried to create a tx whose scriptSig was simply OP\_TRUE, the entire script would typically look like:

```
OP_TRUE OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

```

The first script step pushes `1` onto the stack, next it's duplicated, and then the duplicate on top is hashed. After executing these first three script instructions, you'd have:

```
Stack:
HASH160(1)  <-- stack top
1

Remaining (unexecuted) script: <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

```

Next `<PubkeyHash>` is pushed onto the stack, and then the two top elements (`<PubkeyHash>` and `HASH160(1)`) are compared, which causes the script to fail.

In short, because scriptPubKey is added *after* scriptSig, scriptSig has no way to "override" what scriptPubKey tells the script interpreter to eventually execute. (There's no such instruction as "exit immediately with success" that scriptSig could include.)

Finally, user [Bitcoin](https://bitcoin.stackexchange.com/users/24925/bitcoin) also mentioned that BIP62 changes the "in the end, ignore everything but the top of the stack" rule. This will probably be true one day (and would make no difference in this example anyways), however as of today the rules in BIP62 haven't yet been implemented (except for the one also mentioned in BIP66).


---

