CH07: s/nLocktime/nLockTime/

Matches the style used in Bitcoin Core, which matches the style we use
for other terms in this book.

chapters/authorization-authentication.adoc

@@ -788,9 +788,9 @@ Nodes may choose not to relay or mine +RETURN+, or only relay and mine
 [[locktime_limitations]]
 ===== Transaction locktime limitations
 
-+nLocktime+ has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
++nLockTime+ has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
 
-((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction +nLocktime+ to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
+((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction +nLockTime+ to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
 
 * Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
 * Bob may transmit the transaction after 3 months.
@@ -800,7 +800,7 @@ However:
 * Alice can create another transaction, double-spending the same inputs without a locktime. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
 * Bob has no guarantee that Alice won't do that.
 
-It is important to understand the limitations of transaction +nLocktime+. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the locking script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
+It is important to understand the limitations of transaction +nLockTime+. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
 
 ==== Check Lock Time Verify (CLTV)
 
@@ -827,7 +827,7 @@ output-based timelock.
 
 +CLTV+ doesn't replace +nLocktime+, but rather restricts specific UTXO
 such that they can only be spent in a future transaction with
-+nLocktime+ set to a greater or equal value.
++nLockTime+ set to a greater or equal value.
 
 The +CLTV+ opcode takes one parameter as input, expressed as a number in
 the same format as +nLocktime+ (either a block height or Unix epoch
@@ -874,8 +874,8 @@ the transaction invalid if (source: BIP65):
 
 1. the stack is empty; or
 1. the top item on the stack is less than 0; or
-1. the lock-time type (height versus timestamp) of the top stack item and the +nLocktime+ field are not the same; or
-1. the top stack item is greater than the transaction's +nLocktime+ field; or
+1. the lock-time type (height versus timestamp) of the top stack item and the +nLockTime+ field are not the same; or
+1. the top stack item is greater than the transaction's +nLockTime+ field; or
 1. the +nSequence+ field of the input is 0xffffffff.
 
 [NOTE]