1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-26 01:50:42 +00:00

Edited ch07.asciidoc with Atlas code editor

This commit is contained in:
judymcconville@roadrunner.com 2017-05-01 11:34:53 -07:00
parent ebb43a9224
commit dd0d2f8880

View File

@ -304,7 +304,7 @@ The standard is defined in https://github.com/bitcoin/bips/blob/master/bip-0065.
==== Relative Timelocks
+nLocktime+ and +CLTV+ are ((("timelocks", "relative timelocks")))((("scripting", "timelocks", "relative timelocks")))((("relative timelocks")))both _absolute timelocks_ in that they specify an absolute point in time. The next two timelock features we will examine are _relative timelocks_ in that they specify, as a condition of spending an output, an elapsed time from the confirmation of the output in the blockchain.
+nLocktime+ and +CLTV+ are ((("timelocks", "relative timelocks", id="Trelative07")))((("scripting", "timelocks", "relative timelocks")))((("relative timelocks", id="relativetime07")))both _absolute timelocks_ in that they specify an absolute point in time. The next two timelock features we will examine are _relative timelocks_ in that they specify, as a condition of spending an output, an elapsed time from the confirmation of the output in the blockchain.
Relative timelocks are useful because they allow a chain of two or more interdependent transactions to be held off chain, while imposing a time constraint on one transaction that is dependent on the elapsed time from the confirmation of a previous transaction. In other words, the clock doesn't start counting until the UTXO is recorded on the blockchain. This functionality is especially useful in bidirectional state channels and Lightning Networks, as we will see in <<state_channels>>.