EQUALVERIFY fix and tip

ch06.asciidoc

@@ -456,7 +456,7 @@ First, the unlocking script is executed, using the stack execution engine. If th
 For example, let's look at Alice's payment to Bob's Cafe again. Alice made a payment of 0.015 bitcoin to the cafe's bitcoin address. That transaction output would have a locking script of the form:
 
 ----
-OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
+OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
 ----
 
 The +Cafe Public Key Hash+ is equivalent to the bitcoin address of the cafe, without the Base58Check encoding. Most applications would show the _public key hash_ in hexadecimal encoding and not the familiar bitcoin address Base58Check format that begins with a "1".
@@ -471,7 +471,7 @@ The two scripts together would form the following combined validation script:
 
 ----
 <Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160
-<Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
+<Cafe Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
 ----
 
 When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the cafe's private key that corresponds to the public key hash set as an encumbrance.

ch07.asciidoc

@@ -264,13 +264,13 @@ The +CLTV+ opcode takes one parameter as input, expressed as a number in the sam
 In order to lock an output with +CLTV+, you insert it into the redeem script of the output, in the transaction that creates the output. For example, if Alice is paying Bob's address, the output would normally contain a P2PKH script like this:
 
 ----
-DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY
+DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY CHECKSIG
 ----
 
 To lock it to a time, say 3 months from now, the transaction would be a P2SH transaction with a redeem script like this:
 
 ----
-<now + 3 months> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY
+<now + 3 months> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <Bob's Public Key Hash> EQUALVERIFY CHECKSIG
 ----
 
 where +<now {plus} 3 months>+ is a block height or time value estimated 3 months from the time the transaction is mined: current block height {plus} 12,960 (blocks) or current Unix epoch time {plus} 7,760,000 (seconds). For now, don't worry about the +DROP+ opcode that follows +CHECKLOCKTIMEVERIFY+, it will be explained shortly.
@@ -477,6 +477,11 @@ The script with +IF+ does the same thing as using an opcode with a +VERIFY+ suff
 
 So, when do we use +VERIFY+ and when do we use +IF+? If all we are trying to do is to attach a pre-condition (guard clause), then +VERIFY+ is better. If however, we want to have more than one execution path (flow control), then we need an +IF...ELSE+ flow control clause.
 
+[TIP]
+====
+An opcode such as EQUAL will push the result (TRUE/FALSE) onto the stack, leaving it there for evaluation by subsequent opcodes. In contrast, the opcode EQUALVERIFY suffix does not leave anything on the stack. Opcodes that end in VERIFY do not leave the result on the stack. 
+====
+
 ==== Using Flow Control in Scripts
 
 A very common use for flow control in Bitcoin Script, is to construct a redeem script that offers multiple execution paths, each a different way of redeeming the UTXO.