<p><code>1 &lt;&lt; 31</code> 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.</p>
<p>This means that <code>0x7fffffff</code> is the threshold in big endian.</p>

CC BY-SA 4.0
2023-11-02T00:18:21.690Z
"`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
CC BY-SA 4.0
2023-11-02T00:22:38.033Z
`<<` represents left push. Since you are pushing 31 times, you are setting most left bit and it is most significant bit?
LeaBit
CC BY-SA 4.0
2023-11-02T02:00:12.460Z
`1 << 31` is setting the 31st bit, starting from the least significant one. Is that clearer?
Pieter Wuille
CC BY-SA 4.0
2023-11-02T02:25:42.077Z
@PieterWuille Yes, that's clearer. In other words, it means setting the most significant bit, that is the most left one?
LeaBit
CC BY-SA 4.0
2023-11-02T02:26:31.573Z
@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
CC BY-SA 4.0
2023-11-02T02:44:00.043Z
@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
CC BY-SA 4.0
2023-11-02T02:48:38.537Z
@LeaBit I believe so.
Pieter Wuille
CC BY-SA 4.0
2023-11-02T00:01:46.340Z
2023-12-02T20:31:11.747Z
2023-12-02T20:31:11.747Z
Ava Chow
<p>Based on <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a>, relative lock time is activated if the most significant bit in <code>nSequence</code> value is <strong>not</strong> set. In other words, if the 32th (1&lt;&lt;31) bit is not set. So for the <code>nSequence</code> values less-equal than:</p>
<ol>
<li><code>01111111111111111111111111111111</code> in binary</li>
<li><code>0x7FFFFFFF</code> in hexadecimal</li>
</ol>
<p>... relative lock time is activated.</p>
<p>However, in the <code>Ugam Kamat's</code> <a href="https://bitcoin.stackexchange.com/a/87376/145749">answer</a>, he said that the relative lock time is activated for a <code>nSequence</code> values less than <code>0xEFFFFFFF</code>.</p>
<blockquote>
<p>If <code>nSequence &lt;= 0xEFFFFFFF</code>, it implies relative locktime.</p>
</blockquote>
<p><strong>1. How is it possible? What is correct upper value to activate relative time lock?</strong></p>
<p>Also, for activating just an absolute lock time without relative lock time, he said in his <a href="https://bitcoin.stackexchange.com/a/88290/145749">answer</a> that the nSequence must be between <code>0xF0000000</code> and <code>0xFFFFFFFD</code> (to also activate RBF).</p>
<blockquote>
<p>So for using <code>nLocktime</code> along with Opt-in RBF, your <code>nSequence</code> value has to be between 0xF0000000 to 0xFFFFFFFD.</p>
</blockquote>
<p>However, based on <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a>, to deactivate relative lock time it is only necessary to <strong>set</strong> most significant bit (32th bit) in the <code>nSequence</code>. So for the <code>nSequence</code> values greater-equal than:</p>
<ol>
<li><code>10000000000000000000000000000000</code> in binary</li>
<li><code>0x80000000</code> in hexadecimal</li>
</ol>
<p>... relative lock time is not activated.</p>
<p><strong>2. What is the smallest value we can set for <code>nSequences</code> so that only the absolute lock time is activated without the relative one?</strong></p>

CC BY-SA 4.0
2023-11-01T22:10:31.543Z
I assume this is just a typo/thinko in Ugam's answer.
Pieter Wuille
CC BY-SA 4.0
2023-11-01T22:14:09.353Z
@PieterWuille Okay, what would be the correct answer for example for the first question? I would say `0x7FFFFFFF` and he said `0xEFFFFFFF`.
LeaBit
CC BY-SA 4.0
2023-11-01T22:19:57.523Z
@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
CC BY-SA 4.0
2023-11-01T22:25:56.817Z
@PieterWuille Almost 5 years ago, `skaht` in his [question](https://bitcoin.stackexchange.com/questions/83486/is-the-bit-encoding-format-for-the-graphic-in-bip-68-implicitly-little-endian?rq=1) pointed to this problem.
LeaBit
<locktime><sequence>
What are the correct "threshold" values of the nSequence in order to activate relative time lock and only absolute time lock?
LeaBit
# What are the correct "threshold" values of the nSequence in order to activate relative time lock and only absolute time lock?

(Asked by: username_0 on 2023-11-01)

Based on [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), 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](https://bitcoin.stackexchange.com/a/87376/145749), 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](https://bitcoin.stackexchange.com/a/88290/145749) 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](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), 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?**

**Tags:** locktime, sequence

> **Comments:**
> **username_1**: I assume this is just a typo/thinko in Ugam's answer.  
> **username_0**: @username_1 Okay, what would be the correct answer for example for the first question? I would say `0x7FFFFFFF` and he said `0xEFFFFFFF`.  
> **username_0**: @username_1 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`.  
> **username_0**: @username_1 Almost 5 years ago, `skaht` in his [question](https://bitcoin.stackexchange.com/questions/83486/is-the-bit-encoding-format-for-the-graphic-in-bip-68-implicitly-little-endian?rq=1) pointed to this problem.  

---

## 1 answers

### Answer by username_2 on 2023-11-02. Score: 1 | Accepted answer

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

> **Comments:**
> **username_0**: "`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?  
> **username_0**: `<<` represents left push. Since you are pushing 31 times, you are setting most left bit and it is most significant bit?  
> **username_1**: `1 << 31` is setting the 31st bit, starting from the least significant one. Is that clearer?  
> **username_0**: @username_1 Yes, that's clearer. In other words, it means setting the most significant bit, that is the most left one?  
> **username_1**: @username_0 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.  
> **username_0**: @username_1 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`?  
> **username_1**: @username_0 I believe so.  

---

