Pieter Wuille gave an amazing answer related to the connection between nSequence and nLocktime in the early days of Bitcoin.
However, based on his answer it looks like the
nLocktime was NOT really originally intended just for the absolute time lock in sense
you cannot include this transaction in the blockchain before the UTC timestamp/block height defined in nLocktime pass.
As I understood,
nLocktime was more intended to work together with the
nSequence as a time bound in sense how much time we will wait in mempool for the transaction to become final in context of replacing, than to be just absolute time lock. If we want our transaction to immediately become "final" (ready for the blockchain) then we just need to set all
nSequence to 0xffffffff. Since there will be no replacement, there is no need to wait for anything, so the
nLocktime value is ignored. Also, we can set
nLocktime to zero and since we don't wait any time for the replacement, in this case the transaction also becomes immediately "final" regardless of the value of
So I would say that the
nLocktime is originally intended to be the time in which we will wait for a replacement. However, as we can set the
nSequence to, for example,
0xfffffffe and never increase it and set the
nLocktime to some time (UTC timestamp/block height), then the
nLocktime indirectly becomes, and can be used, as the absolute timelock.
As addition. It doesn't work that way today. This relationship between the
nSequence value and the
nLocktime value still remained as a consensus rule (would require hard fork to change), so if all
nSequences are 0xffffffff, then the
nLocktime value is not considered, and otherwise
nLocktime can be used as an absolute timelock. However, replacement today has nothing to do with
nSequence (it just must be less than 0xffffffff-1 and that is all), nor wait for
What do you think? What was the first original purpose of the
nLocktime? Am I right?