It was brought to my attention that BOLT 3 does a cute trick to encode the commitment transaction number split across the transaction’s nLockTime and the input’s nSequence number. This trick uses up 7.34% of the currently unallocated but usable space in nLockTime, and a truly negligible 0.78% of the unallocated but usable space of nSequence. I did a quick search of the bitcoin developer mailing list archives and was not able to see any discussion of this application-specific usage of the reserved space of these two fields.
Personally I think this is a reasonable compromise to make, to allow the BOLT 3 design to save 6 vbytes per transaction. There are probably other applications too which would benefit from 24 bits of data storage in either nLockTime or nSequence. However with my protocol engineer hat on I should point out that moving forward over time it is not necessarily the case that these bits will be available for use. Just as a significant range of nSequence was set aside for relative lock-time in BIP 68, it is entirely possible that future protocol upgrades will make use of this space. It is unlikely that such a change would break existing lightning transactions since, like BIP 68, such new features would be gated by a transaction version number update. But it would mean that such new features would be incompatible with lightning transactions without a change to BOLT 3. I would suggest that those involved in crafting the BOLT 3 specification put forward a proposal to the bitcoin developer community to allocate this space for data storage, thereby protecting it from future protocol changes, as well as being polite in letting the wider developer community know what reserved space lightning is using. Cheers, Mark Friedenbach _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
