From d3560ce7fc70ecd023ff7398cd55e804765ee2b4 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Tue, 4 Apr 2017 12:51:48 -0700 Subject: [PATCH 1/2] EQUALVERIFY fix and tip --- ch06.asciidoc | 4 ++-- ch07.asciidoc | 9 +++++++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index 501bfa29..fbd65160 100644 --- a/ch06.asciidoc +++ b/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 OP_EQUAL OP_CHECKSIG +OP_DUP OP_HASH160 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: ---- OP_DUP OP_HASH160 - OP_EQUAL OP_CHECKSIG + 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. diff --git a/ch07.asciidoc b/ch07.asciidoc index 2702714a..66df780d 100644 --- a/ch07.asciidoc +++ b/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 EQUALVERIFY +DUP HASH160 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: ---- - CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY + CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG ---- where ++ 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. From 020a9c091d7f8a44cf4bd12333455e52c180f464 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Tue, 4 Apr 2017 12:52:05 -0700 Subject: [PATCH 2/2] additional changelog --- second_edition_changes.asciidoc | 34 +++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/second_edition_changes.asciidoc b/second_edition_changes.asciidoc index 023ea452..38ac1310 100644 --- a/second_edition_changes.asciidoc +++ b/second_edition_changes.asciidoc @@ -41,3 +41,37 @@ * Signature serialization (DER encoding) * SIGHASH flags * ECDSA Math overview + + +== Chapter 7 + +* Time Locks + * Transaction level absolute (nLocktime) + * UTXO/Script level absolute (CHECKLOCKTIMEVERIFY) + * Input level relative (nSequence) + * UTXO/Script level relative (CHECKSEQUENCEVERIFY) +* Median Time Past +* Timelock defense against fee sniping +* Script Flow Control +* VERIFY guard clauses +* Time lock guard clauses +* Complex script (example and analysis) + +== Chapter 8 + +* Relay networks +* SPV node improvements +* Bloom filters and SPV +* SPV nodes and privacy +* Encrypted and Authenticated connections (BIP150/151) + +== Chapter 9 + +* Merkle trees and SPV +* Test blockchains + * Testnet + * Using testnet + * Segnet + * Regtest + * Using regtest +* Development with test blockchains