Exploring Extended Relative Timelocks

Posted by sjors

Aug 4, 2025/11:24 UTC

The discussion revolves around a specific aspect of the Bitcoin Improvement Proposal 68 (BIP68), which introduced relative lock-time using nSequence. The suggestion is to expand the current mask used in BIP68 from 0x0000ffff to 0x0001ffff by including an additional bit, specifically bit 16. This change proposes a method for enhancing the functionality of the protocol, allowing for more nuanced control over transaction lock times.

The primary advantage of this modification would be to introduce a soft fork, enabling new features while maintaining backward compatibility with older software versions. Older software versions would interpret transactions with the 16th bit set as being spendable earlier than they are under the proposed new rules. However, there's a significant caveat to consider: if bit 16 were accidentally set by a user, it could lead to an unexpected and potentially problematic delay. Specifically, transactions could be locked for a decade longer than the user intended, leading to funds being inaccessible for that period.

This proposal underscores the delicate balance between advancing blockchain technology and ensuring user safety and accessibility. It highlights the need for careful consideration and robust debate within the development community before implementing changes that could have far-reaching implications.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback