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?

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

1 Answers1

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.

Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
Ava Chow
  • 70,382
  • 5
  • 81
  • 161
  • 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 Nov 02 '23 at 00:18
  • << represents left push. Since you are pushing 31 times, you are setting most left bit and it is most significant bit? – LeaBit Nov 02 '23 at 00:22
  • 1 << 31 is setting the 31st bit, starting from the least significant one. Is that clearer? – Pieter Wuille Nov 02 '23 at 02:00
  • @PieterWuille Yes, that's clearer. In other words, it means setting the most significant bit, that is the most left one? – LeaBit Nov 02 '23 at 02: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 Nov 02 '23 at 02:26
  • @PieterWuille I do not want to complicate and waste your time, so the answer on the first question is 0x7FFFFFFF and on the second is 0x80000000? – LeaBit Nov 02 '23 at 02:44
  • @LeaBit I believe so. – Pieter Wuille Nov 02 '23 at 02:48