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?

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

  • 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
    Oct 29, 2023 at 15:37
  • You need to look at the definition of the IsFinal method on CTransaction: github.com/bitcoin/bitcoin/blob/…. It calls CTxIn's own IsFinal method for each input. This method checks the nSequence is 0xffffffff. See github.com/bitcoin/bitcoin/blob/…. Oct 29, 2023 at 16:19
  • I am not a programmer. I do not understand the code that much. I posted a new question related to this. bitcoin.stackexchange.com/questions/120256/…
    – LeaBit
    Oct 29, 2023 at 16:24
  • My bad. Brainfart. I wrote this backward: nLockTime is disregarded if all inputs are final. I updated my answer accordingly. Oct 29, 2023 at 16:31
  • 1
    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
    Oct 29, 2023 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.