<p><strong>You are looking at a <em>Commitment Transaction</em>. Commitment transactions are submitted to the network by one channel owner to unilaterally close a Lightning Network channel. The locktime in commitment transactions is used to communicate channel state which results in all commitment transactions being locked to a date in 1987.</strong></p>
<p>Bolt3 <a href="https://github.com/lightning/bolts/blob/316882fcc5c8b4cf9d798dfc73049075aa89d3e9/03-transactions.md#commitment-transaction" rel="nofollow noreferrer">specifies</a> that commitment transactions store an <em>obscured commitment transaction number</em> (i.e. the &quot;edition&quot; of the commitment) split across the <code>locktime</code> and <code>sequence</code> fields. This makes it easier for the channel owner to identify whether the latest or an older commitment transaction was broadcast by the counterparty.</p>
<p>The commitment transaction number is not stored in plaintext but obscured by XORing it with a shared secret created by hashing the concatenated <code>payment_basepoint</code> from  the <code>open_channel</code> and <code>accept_channel</code> messages. Since the channel owners know these basepoints, they can revert the XOR to read the encoded data, but the data appears pseudorandom to any third parties.</p>
<p>In both the <code>locktime</code> and <code>sequence</code>, the upper byte is fixed, while the lower three bytes each store three bytes of the obscured commitment transaction number. In the <code>locktime</code> the upper byte must be set to <code>0x20</code>, so the <code>locktime</code> of a commitment transaction must always fall in [0x20000000, 0x20ffffff], i.e.</p>
<blockquote>
<p>536870912<sub>10</sub> ≤ <code>locktime</code> ≤ 553648127<sub>10</sub></p>
</blockquote>
<p>which will always results in a time-based locktime to a date between 1987-01-05 and 1987-07-18.</p>

CC BY-SA 4.0
2022-12-29T19:27:16.587Z
2022-12-29T20:39:39.707Z
2022-12-29T20:39:39.707Z
Murch
<p>I don't understand the locktime in transaction <code>97DC62BAB016D8EE5C828C76318FE01E9A70992F150838960122DFA9BF8089BC</code></p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Hexadecimal Data</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td>82BF3B20</td>
<td>LockTime 1987-02-20 02:29</td>
</tr>
</tbody>
</table>
</div>
<p>The locktime is 0x82BF3B20 or 540,786,562 which is greater than 500,000,000 so should be interpreted as a date. But that would be a date in 1987. Is there any known reason to specify a date so far in the past?</p>

<transactions><locktime><ln-commitment-transaction>
Why would a transaction have a locktime of 1987!
RedGrittyBrick
# Why would a transaction have a locktime of 1987!

(Asked by: username_0 on 2022-10-12)

I don't understand the locktime in transaction `97DC62BAB016D8EE5C828C76318FE01E9A70992F150838960122DFA9BF8089BC`

| Hexadecimal Data | Meaning |
| --- | --- |
| 82BF3B20 | LockTime 1987-02-20 02:29 |

The locktime is 0x82BF3B20 or 540,786,562 which is greater than 500,000,000 so should be interpreted as a date. But that would be a date in 1987. Is there any known reason to specify a date so far in the past?

**Tags:** transactions, locktime, ln-commitment-transaction


---

## 1 answers

### Answer by username_1 on 2022-12-29. Score: 4

**You are looking at a *Commitment Transaction*. Commitment transactions are submitted to the network by one channel owner to unilaterally close a Lightning Network channel. The locktime in commitment transactions is used to communicate channel state which results in all commitment transactions being locked to a date in 1987.**

Bolt3 [specifies](https://github.com/lightning/bolts/blob/316882fcc5c8b4cf9d798dfc73049075aa89d3e9/03-transactions.md#commitment-transaction) that commitment transactions store an *obscured commitment transaction number* (i.e. the "edition" of the commitment) split across the `locktime` and `sequence` fields. This makes it easier for the channel owner to identify whether the latest or an older commitment transaction was broadcast by the counterparty.

The commitment transaction number is not stored in plaintext but obscured by XORing it with a shared secret created by hashing the concatenated `payment_basepoint` from the `open_channel` and `accept_channel` messages. Since the channel owners know these basepoints, they can revert the XOR to read the encoded data, but the data appears pseudorandom to any third parties.

In both the `locktime` and `sequence`, the upper byte is fixed, while the lower three bytes each store three bytes of the obscured commitment transaction number. In the `locktime` the upper byte must be set to `0x20`, so the `locktime` of a commitment transaction must always fall in [0x20000000, 0x20ffffff], i.e.

> 53687091210 ≤ `locktime` ≤ 55364812710

which will always results in a time-based locktime to a date between 1987-01-05 and 1987-07-18.


---

