diff --git a/chapters/authorization-authentication.adoc b/chapters/authorization-authentication.adoc index 8fd30ab8..b657e413 100644 --- a/chapters/authorization-authentication.adoc +++ b/chapters/authorization-authentication.adoc @@ -608,9 +608,9 @@ If the redeemScript hash matches, the redeemScript is executed: ((("scripting", "Pay-to-Script-Hash", "addresses")))((("Pay-to-Script-Hash (P2SH)", "addresses")))((("bitcoin -improvement proposals", "Address Format for P2SH (BIP-13)")))Another +improvement proposals", "Address Format for P2SH (BIP13)")))Another important part of the P2SH feature is the ability to encode a script -hash as an address, as defined in BIP-13. P2SH addresses are Base58Check +hash as an address, as defined in BIP13. P2SH addresses are Base58Check encodings of the 20-byte hash of a script, just like Bitcoin addresses are Base58Check encodings of the 20-byte hash of a public key. P2SH addresses use the version prefix "5," which results in @@ -809,10 +809,10 @@ Lock Time Verify (CLTV)")))((("scripting", "timelocks", "Check Lock Time Verify (CLTV)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY (BIP-65)")))In December 2015, a new form of timelock was introduced to Bitcoin as a soft fork upgrade. Based on a -specification in BIP-65, a new script operator called _CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language. +CLTV+ is a per-output timelock, rather than a per-transaction timelock as is the case with +nLocktime+. This allows for much greater +specification in BIP65, a new script operator called flexibility in the way timelocks are applied. In simple terms, by adding the +CLTV+ opcode in the redeemScript of an @@ -870,7 +870,7 @@ operation” or NOP opcode was executed). Otherwise, script execution halts and the transaction is deemed invalid. More precisely, +CHECKLOCKTIMEVERIFY+ fails and halts execution, marking -the transaction invalid if (source: BIP-65): +the transaction invalid if (source: BIP65): 1. the stack is empty; or 1. the top item on the stack is less than 0; or @@ -903,8 +903,8 @@ language, +CLTV+ allows us to develop some very interesting complex scripts.((("", startref="cltv07"))) The standard is defined in -https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP-65 -(CHECKLOCKTIMEVERIFY)]. +https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65 +(OP_CHECKLOCKTIMEVERIFY)]. ==== Relative Timelocks @@ -932,15 +932,15 @@ transaction input. Script-level relative timelocks are implemented with the +CHECKSEQUENCEVERIFY+ (CSV) opcode. ((("bitcoin improvement proposals", "Relative lock-time using -consensus-enforced sequence numbers (BIP-68)")))((("bitcoin improvement -proposals", "CHECKSEQUENCEVERIFY (BIP-112)")))Relative timelocks are +consensus-enforced sequence numbers (BIP68)")))((("bitcoin improvement +proposals", "CHECKSEQUENCEVERIFY (BIP112)")))Relative timelocks are implemented according to the specifications in -https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP-68, +https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68, Relative lock-time using consensus-enforced sequence numbers] and -https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP-112, -CHECKSEQUENCEVERIFY]. +https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112, +OP_CHECKSEQUENCEVERIFY]. -BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to +BIP68 and BIP112 were activated in May 2016 as a soft fork upgrade to the consensus rules. ==== Relative Timelocks with CSV @@ -970,8 +970,8 @@ specified in the relative timelock. One application of this use case can be seen in <> and <>.((("", startref="relativetime07")))((("", startref="Trelative07"))) -+CSV+ is defined in detail in -https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP-112, ++OP_CSV+ is defined in detail in +https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112, CHECKSEQUENCEVERIFY]. === Scripts with Flow Control (Conditional Clauses)