0

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?

Improve this question
4
  • I assume this is just a typo/thinko in Ugam's answer.
    – Pieter Wuille
    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.
    – LeaBit
    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.
    – LeaBit
    Commented Nov 1, 2023 at 22:19
  • @PieterWuille Almost 5 years ago, skaht in his question pointed to this problem.
    – LeaBit
    Commented Nov 1, 2023 at 22:25

1 Answer 1

Reset to default
1

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.

Improve this answer
7
  • 1
    "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?
    – LeaBit
    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?
    – LeaBit
    Commented Nov 2, 2023 at 0:22
  • 1 << 31 is setting the 31st bit, starting from the least significant one. Is that clearer?
    – Pieter Wuille
    Commented Nov 2, 2023 at 2:00
  • @PieterWuille Yes, that's clearer. In other words, it means setting the most significant bit, that is the most left one?
    – LeaBit
    Commented Nov 2, 2023 at 2:25
  • @LeaBit Whether that's the left or the right one depends on your notation. In C-like language parlance, a "left shift" is by definition a multiplication by two, so leftmost there means most significant. But in most computer hardware representations, the least significant bytes come first.
    – Pieter Wuille
    Commented Nov 2, 2023 at 2:26

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.