arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2025-02-16 17:42:06 +00:00
Code Issues Releases Wiki Activity

Edited ch07.asciidoc with Atlas code editor

Browse Source
This commit is contained in:
nadams 2017-04-24 13:35:56 -07:00
parent d908614787
commit 40c21e203b
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ch07.asciidoc
View File

@ -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>>.