From 583b1f5a2dacce2f605e1169984bba60b1798a1e Mon Sep 17 00:00:00 2001 From: nadams Date: Mon, 24 Apr 2017 13:29:20 -0700 Subject: [PATCH] Edited ch07.asciidoc with Atlas code editor --- ch07.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index b9ddd787..39d41c25 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -277,7 +277,7 @@ To lock it to a time, say 3 months from now, the transaction would be a P2SH tra 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. -When Bob tries to spend this UTXO, he constructs a transaction that references the UTXO as an input. He uses his signature and public key in the unlocking script of that input and sets the transaction nLocktime to be equal or greater to the timelock in the +CHECKLOCKTIMEVERIFY+ Alice set. Bob then broadcasts the transaction on the bitcoin network. +When Bob tries to spend this UTXO, he constructs a transaction that references the UTXO as an input. He uses his signature and public key in the unlocking script of that input and sets the transaction +nLocktime+ to be equal or greater to the timelock in the +CHECKLOCKTIMEVERIFY+ Alice set. Bob then broadcasts the transaction on the bitcoin network. Bob's transaction is evaluated as follows. If the +CHECKLOCKTIMEVERIFY+ parameter Alice set is less than or equal the spending transaction's +nLocktime+, script execution continues (acts as if a NOP opcode was executed). Otherwise, script execution halts and the transaction is deemed invalid. @@ -300,7 +300,7 @@ By using nLocktime in conjunction with +CLTV+, the scenario described in <