What are all the meanings of the nSequence field?

Question

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?

Answer 1

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".

However this field was also attached a consensus meaning early on. On October 29th 2009 Satoshi (in commit cc0b4c3b62367a2aebe5fc1f4d0ed4b97e9c2ac9) 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 on this topic.

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

• Relative timelocks. This is consensus. BIP68 specifies 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.

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.