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?
This seems to be a pattern with lot of force closed channels tx.
Reason:
We are using the locktime to communicate information about the commitment that is being settled, see the spec for details.
https://github.com/ElementsProject/lightning/issues/1112#issuecomment-368657578
Examples:
c9714be517c92e95710f6fdae8992f6a7f6f64b4c7bb5bd2b65b5c3400a328e8
8df8b53b482999a8c274f06cf49c4b3457327e81591f3074ecfd65954913e32e
ecc0f48e392f72e515ebbc7ef43f1630a511853285f1249e00d7c2d3ca0d7f9f
56e08e56152ab3454eaf5f709cbf76ecc1ca30e6cb4998519f447482ec0c8135
62df2ff96ba9a4bcf825a69da1cb95e799783d9376722f2930b33ab76836046c
Note: nLocktime for mutually closed channel txs is zero
Steps to test nLocktime for forced closed channels:
I found a list of closed channels on 1ML: https://1ml.com/channel?order=closedchannels
Checked a few transactions on https://mempool.space
Clicked the yellow tag
Confirmed that channel was force closed
Locktime in closing tx is 549,167,427
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 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.