<p>If you look at <code>git blame</code> of BOLT 03 you can track the sentence regarding the locktime down to this commit: <a href="https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982" rel="nofollow noreferrer">https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982</a></p>

<p>luckily the author gave a good explanation in the commitment message in git of why the <code>0x20</code> was introduced for the upper 8 bits in the locktime field (I have nothing to add to this): </p>

<pre><code>Use 0x20 as high byte for locktime in commitment transaction

The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.

Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.
</code></pre>

<p>Similarly for the first 8 bits of the sequence number we find this commit: <a href="https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1" rel="nofollow noreferrer">https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1</a> From the commit message I can quote again: </p>

<pre><code> BOLT 3: Fix commitment transaction input sequence number.

From BIP 68:

    If bit (1 &lt;&lt; 31) of the sequence number is set, then no consensus
    meaning is applied to the sequence number and can be included in any
    block under all currently possible circumstances.

Which is what we want.

</code></pre>

CC BY-SA 4.0
2019-11-11T08:30:00.587Z
Ah okay that makes a lot of sense!

So if I understand correctly, technically for the sequence number, instead of setting the first byte specifically to 0x80, both nodes could agree to set it to any number equal to or higher than 0x80, and use the rest of the 7 bits for storing more data, without it affecting any on-chain consensus?
Darius
CC BY-SA 4.0
2019-11-11T09:45:01.103Z
Yes that seems reasonable. Though it would of course violate the Lightning Network "Consensus" which on the channel level is only local anyway (which specifically means that partners could deviate from it)
Rene Pickhardt
CC BY-SA 4.0
2019-11-11T08:01:58.877Z
2019-11-11T08:01:58.877Z
Rene Pickhardt
<p>In Bolt 3 of the Lightning Network specs, for commitment transactions it states:</p>
<blockquote>
<p>locktime: upper 8 bits are 0x20, lower 24 bits are the lower 24 bits of the obscured commitment number.</p>
<p>sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment number</p>
</blockquote>
<p>What is the reason for those specific upper 8 bits? I understand that the lower 24 bits are effectively arbitrary data used for storing the obscured commitment, but then why not use all 32 bits for both?</p>

<lightning-network><locktime><sequence><ln-commitment-transaction>
In Lightning commitment transactions, what do the upper 8 bits of sequence and locktime represent?
Darius
# In Lightning commitment transactions, what do the upper 8 bits of sequence and locktime represent?

(Asked by: username_0 on 2019-11-11)

In Bolt 3 of the Lightning Network specs, for commitment transactions it states:

> locktime: upper 8 bits are 0x20, lower 24 bits are the lower 24 bits of the obscured commitment number.
>
> sequence: upper 8 bits are 0x80, lower 24 bits are upper 24 bits of the obscured commitment number

What is the reason for those specific upper 8 bits? I understand that the lower 24 bits are effectively arbitrary data used for storing the obscured commitment, but then why not use all 32 bits for both?

**Tags:** lightning-network, locktime, sequence, ln-commitment-transaction


---

## 1 answers

### Answer by username_1 on 2019-11-11. Score: 3 | Accepted answer

If you look at `git blame` of BOLT 03 you can track the sentence regarding the locktime down to this commit: <https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982>

luckily the author gave a good explanation in the commitment message in git of why the `0x20` was introduced for the upper 8 bits in the locktime field (I have nothing to add to this):

```
Use 0x20 as high byte for locktime in commitment transaction

The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.

Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.

```

Similarly for the first 8 bits of the sequence number we find this commit: <https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1> From the commit message I can quote again:

```
 BOLT 3: Fix commitment transaction input sequence number.

From BIP 68:

    If bit (1 << 31) of the sequence number is set, then no consensus
    meaning is applied to the sequence number and can be included in any
    block under all currently possible circumstances.

Which is what we want.

```

> **Comments:**
> **username_0**: Ah okay that makes a lot of sense!  So if I understand correctly, technically for the sequence number, instead of setting the first byte specifically to 0x80, both nodes could agree to set it to any number equal to or higher than 0x80, and use the rest of the 7 bits for storing more data, without it affecting any on-chain consensus?  
> **username_1**: Yes that seems reasonable. Though it would of course violate the Lightning Network "Consensus" which on the channel level is only local anyway (which specifically means that partners could deviate from it)  

---

