# What are the correct "threshold" values of the nSequence in order to activate relative time lock and only absolute time lock?

Based on BIP68, relative lock time is activated if the most significant bit in `nSequence` value is not set. In other words, if the 32th (1<<31) bit is not set. So for the `nSequence` values less-equal than:

1. `01111111111111111111111111111111` in binary
2. `0x7FFFFFFF` in hexadecimal

... relative lock time is activated.

However, in the `Ugam Kamat's` answer, he said that the relative lock time is activated for a `nSequence` values less than `0xEFFFFFFF`.

If `nSequence <= 0xEFFFFFFF`, it implies relative locktime.

1. How is it possible? What is correct upper value to activate relative time lock?

Also, for activating just an absolute lock time without relative lock time, he said in his answer that the nSequence must be between `0xF0000000` and `0xFFFFFFFD` (to also activate RBF).

So for using `nLocktime` along with Opt-in RBF, your `nSequence` value has to be between 0xF0000000 to 0xFFFFFFFD.

However, based on BIP68, to deactivate relative lock time it is only necessary to set most significant bit (32th bit) in the `nSequence`. So for the `nSequence` values greater-equal than:

1. `10000000000000000000000000000000` in binary
2. `0x80000000` in hexadecimal

... relative lock time is not activated.

2. What is the smallest value we can set for `nSequences` so that only the absolute lock time is activated without the relative one?

• I assume this is just a typo/thinko in Ugam's answer. Commented Nov 1, 2023 at 22:10
• @PieterWuille Okay, what would be the correct answer for example for the first question? I would say `0x7FFFFFFF` and he said `0xEFFFFFFF`. Commented Nov 1, 2023 at 22:14
• @PieterWuille I think that confusion also comes from the way BIP68 is written. Since the Bitcoin uses little endian then the picture in this BIP can be assumed also as `11111111111111111111111111111110`, that is `FFFFFFFE`. So most right bit is 0, since it is most significant bit in the case of little endian. Also, since hexadecimal does not have anything with endian it is `0xFEFFFFFF`. However, for me it is more correct `01111111111111111111111111111111`, that is `7FFFFFFF`. In hexadecimal `0x7FFFFFFF`. Commented Nov 1, 2023 at 22:19
• @PieterWuille Almost 5 years ago, `skaht` in his question pointed to this problem. Commented Nov 1, 2023 at 22:25

`1 << 31` is unambiguous. It means set the 31st bit (counting from the least significant bit). How that is represented in memory is irrelevant as numbers always have a least significant bit (0) and a most significant bit.
This means that `0x7fffffff` is the threshold in big endian.
• "`1 << 31` is unambiguous. It means set the 31st least significant bit." Doesn't `1<<31` mean setting the most significant bit, not the least significant bit? Commented Nov 2, 2023 at 0:18
• `<<` represents left push. Since you are pushing 31 times, you are setting most left bit and it is most significant bit? Commented Nov 2, 2023 at 0:22
• `1 << 31` is setting the 31st bit, starting from the least significant one. Is that clearer? Commented Nov 2, 2023 at 2:00