<p>You are right in saying nodes nowadays do not enforce the original ordering meaning given to the <code>nSequence</code> field, though note this was never implemented as part of block validation (couldn't have been). This was indeed &quot;disabled&quot; but was not a change to the consensus rules. We can say it was only &quot;<a href="https://bitcoin.stackexchange.com/q/120269/101498">policy</a>&quot;.</p>
<p>However this field was also attached a consensus meaning early on. On October 29th 2009 Satoshi (in commit <a href="https://github.com/bitcoin/bitcoin/commit/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9#diff-608d8de3fba954c50110b6d7386988f27295de845e9d7174e40095ba5efcf1bbR1221-R1226" rel="nofollow noreferrer"><code>cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9</code></a>) made the <code>IsFinal()</code> function consensus critical. This introduced absolute timelock capability through the <code>nLockTime</code> transaction field, which is disabled if all the transactions inputs have an <code>nSequence</code> that is <code>0xffffffff</code>. See also <a href="https://bitcoin.stackexchange.com/q/90229/101498">this question</a> on this topic.</p>
<p>Nowadays, additional meanings were given to this field. Both &quot;policy&quot; and consensus:</p>
<ul>
<li>Relative timelocks. This is consensus. <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#user-content-Specification" rel="nofollow noreferrer">BIP68 specifies</a> a way of using the first 16 bits of the <code>nSequence</code> to denote a relative locktime either in a number of blocks or as a multiple of 512 seconds. This is only possible if the transaction's <code>nVersion</code> is superior or equal to <code>2</code>. The type is determined by setting the 23rd bit (in seconds) or not (in blocks). The relative timelock may be disabled by setting the 32nd bit.</li>
<li>RBF. This is &quot;policy&quot; only. The Bitcoin Core client has been refusing unconfirmed transactions replacement if the original transaction's inputs all have their <code>nSequence</code> field set to <code>0xfffffffe</code> or <code>0xffffffff</code>. Even if the replacement transaction pays more fees. Note like the original ordering meaning from Satoshi, this <em>cannot</em> be enforced by consensus. And a miner would obviously be incentivized, at least in theory, to not respect this rule. See <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy" rel="nofollow noreferrer">rule #1 from this doc</a>.</li>
</ul>
<p>It's also worth mentioning the Lightning Network specifications have been (ab)using part of <a href="https://github.com/lightning/bolts/blob/master/03-transactions.md#commitment-transaction" rel="nofollow noreferrer">the <code>nSequence</code> field in commitment transactions to store the (obscured) commitment number</a>.</p>

CC BY-SA 4.0
2023-10-29T15:37:36.177Z
You said that nLockTime functionality is `disabled if any of the transaction inputs has an nSequence that is not 0xffffffff` and it is the consensus rule. However, nowhere in the link u left I couldn't see the relation between nSequence and nLocktime. Does this rule still exist? What if I want to enable RBF and put some nSequence different than 0xffffffff? Does it mean that in this case the value of nLocktime won't have any meaning?
LeaBit
CC BY-SA 4.0
2023-10-29T16:19:43.830Z
You need to look at the definition of the `IsFinal` method on `CTransaction`: https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L404-L418. It calls `CTxIn`'s own `IsFinal` method for each input. This method checks the `nSequence` is `0xffffffff`. See https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L232-L235.
Antoine Poinsot
CC BY-SA 4.0
2023-10-29T16:24:47.427Z
I am not a programmer. I do not understand the code that much. I posted a new question related to this. https://bitcoin.stackexchange.com/questions/120256/what-is-the-relation-between-nlocktime-and-nsequence
LeaBit
CC BY-SA 4.0
2023-10-29T16:31:20.317Z
My bad. Brainfart. I wrote this backward: `nLockTime` is disregarded if all inputs are final. I updated my answer accordingly.
Antoine Poinsot
CC BY-SA 4.0
2023-10-29T16:34:45.807Z
So, if I set 0xffffffff to all input nSequence, I can disable nLocktime and absolute timelock, that is, in this case the value of nLocktime does not have any effect?
LeaBit
CC BY-SA 4.0
2023-10-29T16:52:40.417Z
Yes, in this case the value of `nLockTime` would effectively be disregarded.
Antoine Poinsot
CC BY-SA 4.0
2023-10-29T13:59:10.407Z
2023-10-30T17:47:36.523Z
2023-10-30T17:47:36.523Z
Antoine Poinsot
<p>I know the original purpose of the <code>nSequence</code> field was to hold the transaction in the mempool with the transaction being replaced when the larger value comes and so on up to 0xFFFFFFFF when the transaction becomes &quot;finalized&quot; and ready to be mined and included in the block. Since this is not properly implemented, it is completely disabled in Bitcoin.</p>
<p>Now this field has a different purpose and if you don't want any of that, you just need to set the value to 0xFFFFFFFF. However, if the value is not 0xFFFFFFFF, it is an indicator for different things.</p>
<p>For example, if the most significant bit (32nd, or 31 if counting from zero) is not set, it is an indicator for a relative time lock.</p>
<p>But what if the most significant bit is set, what are the other flags? That is, if the 32nd bit is set (1 &lt;&lt; 31)  together with, for example, the 15th or 22nd or 4th bit?</p>
<p>Are there other flags? If so, what are they and any related BIPs about it?</p>
<p>Also, how does the value of <code>nSequence</code> relates to the usage of the <code>nLockTime</code> field?</p>

<replace-by-fee><locktime><sequence><mastering-bitcoin>
What are all the meanings of the nSequence field?
LeaBit
# What are all the meanings of the nSequence field?

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

I know the original purpose of the `nSequence` field was to hold the transaction in the mempool with the transaction being replaced when the larger value comes and so on up to 0xFFFFFFFF when the transaction becomes "finalized" and ready to be mined and included in the block. Since this is not properly implemented, it is completely disabled in Bitcoin.

Now this field has a different purpose and if you don't want any of that, you just need to set the value to 0xFFFFFFFF. However, if the value is not 0xFFFFFFFF, it is an indicator for different things.

For example, if the most significant bit (32nd, or 31 if counting from zero) is not set, it is an indicator for a relative time lock.

But what if the most significant bit is set, what are the other flags? That is, if the 32nd bit is set (1 << 31) together with, for example, the 15th or 22nd or 4th bit?

Are there other flags? If so, what are they and any related BIPs about it?

Also, how does the value of `nSequence` relates to the usage of the `nLockTime` field?

**Tags:** replace-by-fee, locktime, sequence, mastering-bitcoin


---

## 1 answers

### Answer by username_1 on 2023-10-29. Score: 4 | Accepted answer

You are right in saying nodes nowadays do not enforce the original ordering meaning given to the `nSequence` field, though note this was never implemented as part of block validation (couldn't have been). This was indeed "disabled" but was not a change to the consensus rules. We can say it was only "[policy](https://bitcoin.stackexchange.com/q/120269/101498)".

However this field was also attached a consensus meaning early on. On October 29th 2009 Satoshi (in commit [`cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9`](https://github.com/bitcoin/bitcoin/commit/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9#diff-608d8de3fba954c50110b6d7386988f27295de845e9d7174e40095ba5efcf1bbR1221-R1226)) made the `IsFinal()` function consensus critical. This introduced absolute timelock capability through the `nLockTime` transaction field, which is disabled if all the transactions inputs have an `nSequence` that is `0xffffffff`. See also [this question](https://bitcoin.stackexchange.com/q/90229/101498) on this topic.

Nowadays, additional meanings were given to this field. Both "policy" and consensus:

* Relative timelocks. This is consensus. [BIP68 specifies](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#user-content-Specification) a way of using the first 16 bits of the `nSequence` to denote a relative locktime either in a number of blocks or as a multiple of 512 seconds. This is only possible if the transaction's `nVersion` is superior or equal to `2`. The type is determined by setting the 23rd bit (in seconds) or not (in blocks). The relative timelock may be disabled by setting the 32nd bit.
* RBF. This is "policy" only. The Bitcoin Core client has been refusing unconfirmed transactions replacement if the original transaction's inputs all have their `nSequence` field set to `0xfffffffe` or `0xffffffff`. Even if the replacement transaction pays more fees. Note like the original ordering meaning from Satoshi, this *cannot* be enforced by consensus. And a miner would obviously be incentivized, at least in theory, to not respect this rule. See [rule #1 from this doc](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy).

It's also worth mentioning the Lightning Network specifications have been (ab)using part of [the `nSequence` field in commitment transactions to store the (obscured) commitment number](https://github.com/lightning/bolts/blob/master/03-transactions.md#commitment-transaction).

> **Comments:**
> **username_0**: You said that nLockTime functionality is `disabled if any of the transaction inputs has an nSequence that is not 0xffffffff` and it is the consensus rule. However, nowhere in the link u left I couldn't see the relation between nSequence and nLocktime. Does this rule still exist? What if I want to enable RBF and put some nSequence different than 0xffffffff? Does it mean that in this case the value of nLocktime won't have any meaning?  
> **username_1**: You need to look at the definition of the `IsFinal` method on `CTransaction`: https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L404-L418. It calls `CTxIn`'s own `IsFinal` method for each input. This method checks the `nSequence` is `0xffffffff`. See https://github.com/bitcoin/bitcoin/blob/cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9/main.h#L232-L235.  
> **username_0**: I am not a programmer. I do not understand the code that much. I posted a new question related to this. https://bitcoin.stackexchange.com/questions/120256/what-is-the-relation-between-nlocktime-and-nsequence  
> **username_1**: My bad. Brainfart. I wrote this backward: `nLockTime` is disregarded if all inputs are final. I updated my answer accordingly.  
> **username_0**: So, if I set 0xffffffff to all input nSequence, I can disable nLocktime and absolute timelock, that is, in this case the value of nLocktime does not have any effect?  
> **username_1**: Yes, in this case the value of `nLockTime` would effectively be disregarded.  

---

