Exploring Extended Relative Timelocks

The discussion around Bitcoin's 65535-block limit for relative timelocks has sparked curiosity among users of Liana, leading to an exploration of potential methods to extend these timelocks significantly, aiming for durations as long as ~10 years. This initiative stems from the feedback gathered from users who express a need for longer timelock periods, prompting an experimental approach to address this requirement without advocating for immediate changes to the Bitcoin protocol through a soft fork.

A proposed method to achieve extended timelocks involves utilizing bit 21 in the nSequence field of a transaction to signal a "long" timelock. Specifically, the suggestion includes setting bit 21 while ensuring bit 22 remains unset, which would then interpret the timelock unit as being comprised of 8 blocks instead of just one. This adjustment implies that the duration of timelocks could be effectively multiplied by 8, thereby reaching the target duration of approximately 10 years with minimal modifications necessary to the existing Bitcoin Core codebase. However, there's an acknowledgment of potential oversights due to a limited familiarity with the complete intricacies of the Bitcoin Core's architecture.

To facilitate practical experimentation with this concept, a tool and code modification have been developed. The tool is designed for creating addresses and transactions that adhere to a simple policy allowing anyone to spend the assets after the timelock expires. Interested parties can review the experimental code and tool through the provided links: Code change and Tool.

The discourse surrounding this experiment touches on several critical areas:

• The exploration of viable use cases for timelocks extending up to 10 years, questioning whether there are compelling scenarios that necessitate such lengthy durations.

• Consideration of the risks and potential edge cases that might emerge from implementing extended timelocks, including consensus or compatibility issues that may not have been fully considered.

• Alternatives to achieving longer timelocks without resorting to a soft fork, seeking solutions that could accommodate the need for extended durations without significant protocol alterations.

• Evaluation of the proposed implementation strategy using the bit 21 flag paired with 8-block units, inviting feedback on its reasonableness or suggestions for more effective approaches.

This comprehensive examination reflects a cautious yet innovative effort to meet user demands for longer timelock periods in Bitcoin transactions, balancing between technical feasibility and the broader implications for the network and its stakeholders.