2
1
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?
3
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.
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 – 2019-11-11T08:30:00.587
2Yes 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 – 2019-11-11T09:45:01.103