Posted by stevenroose
Jul 14, 2025/09:29 UTC
The discussion revolves around the potential expansion of relative timelock limits, primarily focusing on whether extending these limits to ~10 years would be beneficial and what implications such an extension might have. The conversation highlights that there are indeed compelling use cases for extending the current relative timelock limit beyond its existing threshold, suggesting that a move to a 10-year limit, while seemingly significant, is preferable to the status quo if the alternative is a mere 5-year extension. This perspective underscores the practicality of longer timelocks for certain applications, despite acknowledging that a 10-year period may appear lengthy.
Concerns regarding the proposal mainly focus on the risks associated with locking funds for extended durations, particularly how future soft forks could potentially impact users' access to their coins. The mention of quantum computing as a risk factor is dismissed, given that absolute locktimes currently allow for long-term fund locking, thus negating it as a strong argument against extending relative timelocks. The discussion also touches upon the feasibility of addressing the need for longer timelocks without resorting to a soft fork. It critiques the suggestion of pre-signing a series of relative timelock transactions as impractical and unmanageable, arguing instead that a soft fork might be necessary to implement such changes efficiently and effectively.
Furthermore, the dialogue explores technical considerations for implementing extended timelocks, including the proposal of utilizing a bit 21 flag with 8-block units to maintain granularity while expanding capacity. This approach is praised for its elegance, though it raises questions about whether a longer duration, such as 16 block units yielding a 20-year limit, might be more prudent to avoid future modifications. An additional suggestion involves modifying the starting point for 8 block units to follow the initial 65535 blocks, thereby extending the effective duration by approximately one year and simplifying the representation of relative timelocks.
The enthusiasm for the proposal among some participants stems from its potential to enable new uses, such as Liana-like inheritance constructions, which are currently not feasible due to the 1-year timelock limitation. This indicates a broader interest in exploring and implementing more flexible and extended timelock capabilities to accommodate a wider range of applications and user needs.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback