<p>Based on <code>RedGrittyBrick's</code> <a href="https://bitcoin.stackexchange.com/a/116722/145749">answer</a> and an email Satoshi sent to  Mike Hearn, it appears that the original purpose of <code>nLocktime</code> was indeed as a time bound for replacement and was not intended to be absolute time lock. Since it was never properly implemented, <code>nLocktime</code> is now used as absolute time lock with any <code>nSequence</code> set to a value less than <code>0xffffffff</code>.</p>
<p>So I confirm what I wrote in the question.</p>
<p>I thank <code>RedGrittyBrick</code> once again for his help.</p>

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

CC BY-SA 4.0
2023-10-31T12:03:39.837Z
See https://bitcoin.stackexchange.com/q/116706/13866 re Nakamoto email on this subject in 2011
RedGrittyBrick
<locktime><sequence>
What was the first original purpose of the nLocktime? Was it only the time bound to nSequence?
LeaBit
# What was the first original purpose of the nLocktime? Was it only the time bound to nSequence?

(Asked by: username_0 on 2023-10-31)

Pieter Wuille gave an amazing [answer](https://bitcoin.stackexchange.com/a/120274/145749) 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 `nSequence`.

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 `nSequence`s 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 `nLocktime` time.

What do you think? What was the first original purpose of the `nLocktime`? Am I right?

**Tags:** locktime, sequence

> **Comments:**
> **username_1**: See https://bitcoin.stackexchange.com/q/116706/13866 re Nakamoto email on this subject in 2011  

---

## 1 answers

### Answer by username_0 on 2023-11-01. Score: 3 | Accepted answer

Based on `username_1's` [answer](https://bitcoin.stackexchange.com/a/116722/145749) and an email Satoshi sent to Mike Hearn, it appears that the original purpose of `nLocktime` was indeed as a time bound for replacement and was not intended to be absolute time lock. Since it was never properly implemented, `nLocktime` is now used as absolute time lock with any `nSequence` set to a value less than `0xffffffff`.

So I confirm what I wrote in the question.

I thank `username_1` once again for his help.


---

