Yes, if I understand this limitation correctly, and if there’s no elegant way around it, it makes CTV not practical for vaults. Except perhaps for very sophisticated users, in particular those with existing (reliable, frequent) backup infrastructure.
The use case I have in mind is a “daily” wallet with a recovery mechanism, where if you don’t use the mechanism it shouldn’t get in your way. Otherwise it’s not going to be a UX improvement over the current state of the art of just rotating coins once a year as a dead man’s switch (and having your wallet reminding you).
You can’t know this hash at wallet creation time. Indeed also because you won’t know what lock time to pick. Maybe you could have giant tree of amounts and fixed dates?
Maybe the above is a bit too pessimistic; it doesn’t work for the use case I’m describing, and descriptors aren’t the right tool, but the original Simple-CTV-Vault design seems to only require the user to backup:
- the involved public keys
- one (?) private key
- the block delay
- each deposit transaction id
(1) - (3) are known at creation time. (4) requires continuous backups, but may be recoverable with context.