Edited ch07.asciidoc with Atlas code editor

ch07.asciidoc

@@ -341,7 +341,7 @@ When interpreting +nSequence+ as a relative timelock, only the 16 least signific
 image::images/mbc2_0701.png["BIP-68 definition of nSequence encoding"]
 
 
-Relative timelocks based on consensus enforcement of the +nSequence+ value are defined in BIP-68:
+Relative timelocks based on consensus enforcement of the +nSequence+ value are defined in BIP-68.
 
 The standard is defined in https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP-68 Relative lock-time using consensus-enforced sequence numbers].
 
@@ -351,7 +351,7 @@ Just like CLTV and +nLocktime+, there is a script opcode for relative timelocks
 
 The +CSV+ opcode when evaluated in a UTXO's redeem script, allows spending only in a transaction whose input +nSequence+ value is greater than or equal to the +CSV+ parameter. Essentially, this restricts spending the UTXO until a certain number of blocks or seconds have elapsed relative to the time the UTXO was mined.
 
-As with CLTV, the value in +CSV+ must match the format in the corresponding +nSequence+ value. If +CSV+ is specified in terms of blocks, then so must nSequence. If +CSV+ is specified in terms of seconds, then so must +nSequence+.
+As with CLTV, the value in +CSV+ must match the format in the corresponding +nSequence+ value. If +CSV+ is specified in terms of blocks, then so must +nSequence+. If +CSV+ is specified in terms of seconds, then so must +nSequence+.
 
 Relative timelocks with +CSV+ are especially useful when several (chained) transactions are created and signed, but not propagated, when they're kept "off-chain". A child transaction cannot be used until the parent transaction has been propagated, mined, and aged by the time specified in the relative timelock. One application of this use case can be seen in <<state_channels>> and <<lightning_network>>.