CTV vault output descriptor

In the discussion regarding the practicality of using CheckTemplateVerify (CTV) for vaults, a significant limitation is highlighted. This limitation centers on the complexities and impracticalities that arise when considering CTV's application for daily wallets with a recovery mechanism. The envisioned use case suggests a wallet that does not hinder user experience if its recovery system is not employed. This contrasts sharply with the current methodologies, such as rotating coins annually as part of a dead man's switch strategy, complemented by wallet reminders.

The critique extends to the technical constraints of implementing CTV within this context. Specifically, the challenge lies in the inability to know the preimage of the CTV hash beforehand, as well as deciding on an appropriate lock time during wallet creation. These hurdles suggest an inherent mismatch between the desired functionality of a user-friendly daily wallet and the capabilities offered by CTV when framed within the concept of descriptors—essentially tools meant to describe potentially unlimited storage or transactional capacities.

Despite these criticisms, it's noted that the original Simple-CTV-Vault design might still hold potential under certain conditions. According to discussions in its repository, particularly in this issue, the requirements for users to effectively utilize this design are relatively straightforward. Users would need to maintain backups of the involved public keys, at least one private key, the specified block delay, and each deposit transaction ID. The first three elements are known at the time of vault creation, while the last necessitates ongoing backups but could potentially be reconstructed with adequate contextual information. This somewhat mitigates the original concerns, suggesting that while CTV may not universally enhance user experience across all envisioned use cases, there remains a subset of applications where its implementation could be both practical and beneficial.