From 89826827dd082fe922a96abebd6aee4f4933d367 Mon Sep 17 00:00:00 2001 From: Ed Posnak Date: Fri, 3 Feb 2017 13:04:19 -0500 Subject: [PATCH] add brief explanation for why nSequence cannot be 2^32 --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index e108fbc1..776402ba 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -327,7 +327,7 @@ Relative timelocks can be set on each input of a transaction, by setting the nSe The nSequence field was originally intended (but never properly implemented) to allow modification of transactions in the mempool. In that use, a transaction containing inputs with nSequence value below 2^32^ (0xFFFFFFFF) indicated a transaction that was not yet "finalized". Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher nSequence value. Once a transaction was received whose inputs had an nSequence value of 2^32^ it would be considered "finalized" and mined. -The original meaning of nSequence was never properly implemented and the value of nSequence is customarily set to 2^32^ in transactions that do not utilize timelocks. For transactions with nLocktime or CHECKLOCKTIMEVEIRFY, the nSequence value must be set to less than 2^32^. Customarily, it is set to 2^32^ - 1 (0xFFFFFFFE). +The original meaning of nSequence was never properly implemented and the value of nSequence is customarily set to 2^32^ in transactions that do not utilize timelocks. For transactions with nLocktime or CHECKLOCKTIMEVEIRFY, the nSequence value must be set to less than 2^32^ for the timelock guards to have effect. Customarily, it is set to 2^32^ - 1 (0xFFFFFFFE). ===== nSequence as consensus-enforced relative timelock