When onboarding users to Liana, the most common question I get is whether the timelock can be extended beyond the current 15 months. Personally, I think extending it to 5 or even 10 years would be ideal it would resolve several UX pain points and better align with long-term custody and inheritance needs.
1 Like
I wish the original BIP68 authors had used just one more bit.
Why not just do that and include bit 16? So the mask goes from 0x0000ffff to 0x0001ffff. If bit 16 set, old software would allow spending strictly earlier, so it’s a soft fork. The downside is that if someone set this bit accidentally they’ll have to wait a decade longer than expected.
Because Lightning already uses these bits to store obfuscated commitment transaction numbers. The nSequence bits with no consensus meaning are i think in practice lost as an upgrade hook. I think that if someone wanted to work on extending relative timelocks they should use the Taproot annex, and why not also bundle per-input absolute timelocks under a single “improved timelocks” proposal.
1 Like
Ah, this is burried deep in BOLT 03:
the lower 24 bits of the obscured commitment number
It would be good if Lightning folks opened a BIP similar to BIP320 to document this. cc @rustyrussell ?
1 Like
Interesting remark, thanks.
I’ve take a look about nSequence usage onchain with this [tool](nsequence_runner) and what I can observe is:
- there is no nsequence bit that have not been used at least once
- the combination of bit31 = 0 && bit 22 = 0 && bit 21 = 1 && (nSequence & 0xFFFF) > 0 && the spending script contains an OP_CSV (only looked at segwitv0 & taproot)
I’ve no strong opinion on how it should be interpreted btw