5

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?

2 Answers 2

6

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:

3

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.

53687091210locktime ≤ 55364812710

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.