<p>The image is most significant bit first, aka big endian. When discussing bit shifting, or numbers in general, in computer science, the notation is always big endian since that's the way that the vast majority of people think. When you write code, it's always big endian even though the actual representation in memory may be little endian. So specs will also assume big endian when they are not discussing specific implementation of serialization.</p>
<p>Even though the image is big endian, that does not mean that the sequence itself is big endian. Different endianness assign the positions differently. But the value of each position itself is what actually matters, not how they are ordered. That order only matters when doing serialization which is already well specified.</p>

CC BY-SA 4.0
2023-11-02T00:34:31.460Z
So the first option is the correct one, that is `01111111111111111111111111111111` (`7FFFFFFF`), that's what is used in the code? However, if we talk about serialization (since it is little endian in Bitcoin) it is `FFFFFF7F`?
LeaBit
CC BY-SA 4.0
2023-11-02T00:59:08.147Z
The number sent is `0x7FFFFFFF`, in little endian 32-bit format, which corresponds to the bytes `0xFF, 0xFF, 0xFF, 0x7F`.
Pieter Wuille
CC BY-SA 4.0
2023-11-02T02:46:28.090Z
@PieterWuille So in transaction serialized format it will be `FF FF FF 7F` (since it is little endian) and that's what will be send through network, and in code we work with `7F FF FF FF` (`01111111111111111111111111111111`) as Andrew said that in code its always big endian?
LeaBit
CC BY-SA 4.0
2023-11-02T02:58:43.577Z
In code we don't work with bytes, but with numbers. The source code would contain the string "0x7FFFFFFF", or "2147483647".
Pieter Wuille
CC BY-SA 4.0
2023-11-02T03:00:02.230Z
@PieterWuille Yes, that's what I think. And in serialization form it is `FF FF FF 7F` since its little endian?
LeaBit
CC BY-SA 4.0
2023-11-02T03:02:14.650Z
@PieterWuille When I say serialization form, I think on form for network "transport".
LeaBit
CC BY-SA 4.0
2023-11-02T03:06:22.273Z
@LeaBit Yes, the "FF FF FF 7F" on the network is correct. My comment was about your "7F FF FF FF in the code".
Pieter Wuille
CC BY-SA 4.0
2023-11-02T03:12:32.777Z
@PieterWuille Everything clear then. Thanks
LeaBit
CC BY-SA 4.0
2023-11-01T23:56:59.197Z
2023-11-01T23:56:59.197Z
Ava Chow
<p>The image in <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a> is as follows:</p>
<p><a href="https://i.sstatic.net/XHvIL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XHvIL.png" alt="enter image description here" /></a></p>
<p>So, based on the most significant bit (1&lt;&lt;31) we can activate or deactivate relative lock time.</p>
<p>However, depending on which endian is implied, this image can be interpret in two ways.</p>
<ol>
<li>If the image is interpreted through big endian (which is most often the case with such images), <strong>then this bit is most-left bit</strong>. Therefore <code>01111111111111111111111111111111</code> in binary would activate relative lock time. (NOTE: In practice, of course, all the other bits will not be 1. However, as the point of the question is not in that, I put it that way so that the 0 could be distinguished as much as possible.)</li>
<li>If the image is interpreted through little endian (since Bitcoin uses it, it is logical to look at the image in that way as well), <strong>then this bit is most-right bit</strong>. Therefore <code>11111111111111111111111111111110</code> in binary would activate relative lock time.</li>
</ol>
<p>What is the correct way to interpret this image and to set relative lock time?</p>

<sequence><checksequenceverify>
Is the image in BIP68 represented in context of little or big endian?
LeaBit
# Is the image in BIP68 represented in context of little or big endian?

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

The image in [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) is as follows:

[![enter image description here](https://i.sstatic.net/XHvIL.png)](https://i.sstatic.net/XHvIL.png)

So, based on the most significant bit (1<<31) we can activate or deactivate relative lock time.

However, depending on which endian is implied, this image can be interpret in two ways.

1. If the image is interpreted through big endian (which is most often the case with such images), **then this bit is most-left bit**. Therefore `01111111111111111111111111111111` in binary would activate relative lock time. (NOTE: In practice, of course, all the other bits will not be 1. However, as the point of the question is not in that, I put it that way so that the 0 could be distinguished as much as possible.)
2. If the image is interpreted through little endian (since Bitcoin uses it, it is logical to look at the image in that way as well), **then this bit is most-right bit**. Therefore `11111111111111111111111111111110` in binary would activate relative lock time.

What is the correct way to interpret this image and to set relative lock time?

**Tags:** sequence, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2023-11-01. Score: 1 | Accepted answer

The image is most significant bit first, aka big endian. When discussing bit shifting, or numbers in general, in computer science, the notation is always big endian since that's the way that the vast majority of people think. When you write code, it's always big endian even though the actual representation in memory may be little endian. So specs will also assume big endian when they are not discussing specific implementation of serialization.

Even though the image is big endian, that does not mean that the sequence itself is big endian. Different endianness assign the positions differently. But the value of each position itself is what actually matters, not how they are ordered. That order only matters when doing serialization which is already well specified.

> **Comments:**
> **username_0**: So the first option is the correct one, that is `01111111111111111111111111111111` (`7FFFFFFF`), that's what is used in the code? However, if we talk about serialization (since it is little endian in Bitcoin) it is `FFFFFF7F`?  
> **username_2**: The number sent is `0x7FFFFFFF`, in little endian 32-bit format, which corresponds to the bytes `0xFF, 0xFF, 0xFF, 0x7F`.  
> **username_0**: @username_2 So in transaction serialized format it will be `FF FF FF 7F` (since it is little endian) and that's what will be send through network, and in code we work with `7F FF FF FF` (`01111111111111111111111111111111`) as Andrew said that in code its always big endian?  
> **username_2**: In code we don't work with bytes, but with numbers. The source code would contain the string "0x7FFFFFFF", or "2147483647".  
> **username_0**: @username_2 Yes, that's what I think. And in serialization form it is `FF FF FF 7F` since its little endian?  
> **username_0**: @username_2 When I say serialization form, I think on form for network "transport".  
> **username_2**: @username_0 Yes, the "FF FF FF 7F" on the network is correct. My comment was about your "7F FF FF FF in the code".  
> **username_0**: @username_2 Everything clear then. Thanks  

---

