BIP idea: Timelock-Recovery storage format

The discussion begins with the acknowledgment of a new idea that has potential for a Bitcoin Improvement Proposal (BIP), specifically focusing on enhancing "deadman's switch" systems without the need for constant refreshment. This concept is seen as an improvement over current covenant-less systems, despite concerns about the added complexity it might introduce.

The conversation then shifts to a comparison with existing philosophies and setups, such as those presented by Liana, questioning whether the proposed BIP should offer more flexibility in transaction structures to accommodate a broader range of use cases. This reflects a desire for the proposal to not just be technically feasible but also versatile enough to support various applications within the Bitcoin ecosystem.

A significant technical challenge is highlighted regarding the testmempoolaccept RPC, which fails when testing transactions with relative nSequence locktimes because it requires the UTXO from the Alert Transaction to be confirmed, and the necessary time window to have passed. This issue underscores a critical reliability concern: the need to unequivocally verify that a recovery plan will work before its intended deadline, without risking unintended fund leakage.

Further discussion points to possible solutions, including a suggestion to enhance Bitcoin Core with a feature allowing testmempoolaccept to accept a conditional setting of time or block height as arguments. However, doubts are raised about the feasibility of this solution given the tool's original design purpose and limitations.

Technical specifications of the alert system are also scrutinized, particularly the rationale behind defining alert_inputs separately when this information is already contained within the alert_tx. Additionally, the 388-day limit for the system is critiqued as being somewhat arbitrary, suggesting that while a year may seem like a sufficient duration, it might not meet all use cases' requirements.

Overall, the exchange reflects a deep dive into the technical, philosophical, and practical considerations of proposing a new feature to the Bitcoin protocol, highlighting both the promise of innovative solutions and the complexities involved in their implementation.