<p>While the full policy side of the original <code>nSequence</code> replacement idea was never implemented, it does appear Bitcoin's creator had a design in mind, and the corresponding consensus rules <strong>were</strong> implemented.</p>
<p>In this design, a transaction had a notion of <em>finality</em>. It appears that the idea was that transactions would be replaceable only up until its locktime is hit, and only as long as its sequence values can increase. So, transactions are final if at least one of these is true:</p>
<ul>
<li>Its <code>nLockTime</code> has a height or timestamp in the past.</li>
<li>All its <code>nSequence</code> values were maximal (because such a transaction would not be replaceable by increasing any <code>nSequence</code>).</li>
</ul>
<p>The consensus side of this design called for allowing transactions on-chain which are final (for whatever reason), while the policy side of it requires also accepting non-final transaction into the mempool, and permitting replacement there.</p>
<p>This replacement logic in the mempool was never fully implemented, and found impossible to align with incentive compatibility and DoS resistance (by permitting effectively free relay and processing, by continuously replacing transactions). However, the consensus rules exist, and were - for better or worse - never changed. Dropping the &quot;All <code>nSequence</code> values are maximal implies finality&quot; rule would be a hard fork, with little benefit. It seems unlikely that anyone could manage to go through the tremendous effort of getting the ecosystem to agree to a hardfork for an edge case that can be trivially avoided by wallets (by just not setting the <code>nSequence</code> value maximal).</p>

CC BY-SA 4.0
2023-10-30T18:43:01.667Z
2023-11-03T22:46:49.443Z
2023-11-03T22:46:49.443Z
Pieter Wuille
<p>The <code>nSequence</code> transaction field was originally intended for a replacement logic, but since it was never well thought out, it was never implemented. However, it has been implemented since the beginning that if the <code>nSequence</code> of all inputs is <code>0xffffffff</code>, then the <code>nLocktime</code> and the absolute time are not activated. Later, some additional features are added like the relative time lock consensus rule by not setting the 32nd bit and the RBF policy rule by setting the value of some <code>nSequence</code> within a transaction to a value less than <code>0xffffffff-1</code>.</p>
<p>However, what I don't understand is why nSequence and nLocktime are made to have any relationship at all? If the nSequence was seen to have no original purpose (back in 2009), why wasn't it simply dropped from the transaction or left for some future purpose (as was eventually done through relative time locking and RBF)? Why did they make any connection between <code>nSequence</code> and <code>nLocktime</code>? If you don't want the absolute timelock, then just set it to 0x00000000 and that's it, <strong>why would it be disabled by setting all <code>nSequences</code> to <code>0xffffffff</code></strong>. I can not understand. Is there any logical reason behind linking these two?</p>

<consensus><locktime><sequence>
What is the logic (if there is) behind linking the nSequence and nLockTime?
LeaBit
# What is the logic (if there is) behind linking the nSequence and nLockTime?

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

The `nSequence` transaction field was originally intended for a replacement logic, but since it was never well thought out, it was never implemented. However, it has been implemented since the beginning that if the `nSequence` of all inputs is `0xffffffff`, then the `nLocktime` and the absolute time are not activated. Later, some additional features are added like the relative time lock consensus rule by not setting the 32nd bit and the RBF policy rule by setting the value of some `nSequence` within a transaction to a value less than `0xffffffff-1`.

However, what I don't understand is why nSequence and nLocktime are made to have any relationship at all? If the nSequence was seen to have no original purpose (back in 2009), why wasn't it simply dropped from the transaction or left for some future purpose (as was eventually done through relative time locking and RBF)? Why did they make any connection between `nSequence` and `nLocktime`? If you don't want the absolute timelock, then just set it to 0x00000000 and that's it, **why would it be disabled by setting all `nSequences` to `0xffffffff`**. I can not understand. Is there any logical reason behind linking these two?

**Tags:** consensus, locktime, sequence


---

## 1 answers

### Answer by username_1 on 2023-10-30. Score: 5 | Accepted answer

While the full policy side of the original `nSequence` replacement idea was never implemented, it does appear Bitcoin's creator had a design in mind, and the corresponding consensus rules **were** implemented.

In this design, a transaction had a notion of *finality*. It appears that the idea was that transactions would be replaceable only up until its locktime is hit, and only as long as its sequence values can increase. So, transactions are final if at least one of these is true:

* Its `nLockTime` has a height or timestamp in the past.
* All its `nSequence` values were maximal (because such a transaction would not be replaceable by increasing any `nSequence`).

The consensus side of this design called for allowing transactions on-chain which are final (for whatever reason), while the policy side of it requires also accepting non-final transaction into the mempool, and permitting replacement there.

This replacement logic in the mempool was never fully implemented, and found impossible to align with incentive compatibility and DoS resistance (by permitting effectively free relay and processing, by continuously replacing transactions). However, the consensus rules exist, and were - for better or worse - never changed. Dropping the "All `nSequence` values are maximal implies finality" rule would be a hard fork, with little benefit. It seems unlikely that anyone could manage to go through the tremendous effort of getting the ecosystem to agree to a hardfork for an edge case that can be trivially avoided by wallets (by just not setting the `nSequence` value maximal).


---

