From aeef5dd41e478526e909e6656608ee31fa1ea2e8 Mon Sep 17 00:00:00 2001 From: "judymcconville@roadrunner.com" Date: Mon, 1 May 2017 11:06:38 -0700 Subject: [PATCH] Edited ch07.asciidoc with Atlas code editor --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index 8aaecad4..0db61ea7 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -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")))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")))((("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. 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 <>.