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

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 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 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 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 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 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 any of the transaction inputs has an nSequence that is not 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 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 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 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.