# Exploring Extended Relative Timelocks

**URL:** <https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818>\
**Category:** Protocol Design\
**Created:** [July 10, 2025, 4:18am UTC](https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818 "2025-07-10T04:18:41Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![AntoineP](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/antoinep/32/483_2.png) [@AntoineP](https://delvingbitcoin.org/u/AntoineP)\
**Post date:** [August 4, 2025, 4:05pm UTC](https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818/23 "2025-08-04T16:05:38Z")

</div>

> [@sjors](#):
>
> Why not just do that and include bit 16?

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.

---

_[View the full topic](https://delvingbitcoin.org/t/exploring-extended-relative-timelocks/1818)._