[Feature Request] Timelock Recovery

[oren-z0]

Hi @craigraw ,

I want to implement a "timelock recovery" feature for Sparrow, similar to the one I've already implemented as an extension for Specter Desktop. Source and explanation video can be found here: https://github.com/oren-z0/timelockrecovery-specter

The idea is that after accumulating significant amount of Bitcoin, users may want to be able to "lock" them for long term, with the following conditions:

1. The user should always be able to move the funds with his super-secret master key (i.e. well-hidden seed words and a memorized passphrase).
2. In case the master key was lost, there could be a way to trigger a timelock-based process to transfer the funds to a secondary wallet. In that timelock-window, if the original user found the master key, he could still move the funds elsewhere, preventing the timelock-based process from completing.

This scenario is especially important for inheritance preparation. Suppose the inheritor hold the keys to the secondary wallet but not to the user's original wallet. If the user has died unexpectedly (together with his memorized passphrase), the inheritor could use the timelock-based process to move the funds to the secondary wallet. However, if the user is still alive, and the inheritor try to activate the timelock-based process maliciously (maybe under threat?), the user can still have enough time to move the funds elsewhere.

The solution is quite simple and involves two transactions that the user has to sign (without broadcasting).

1. Alert transaction: a simple consolidation transaction that moves all the user's funds to a new UTXO in his own wallet.
2. Recovery transaction: a transaction that points to the UTXO of the Alert transaction and moves all the funds to the secondary wallet, and has an nSequence of predefined number of days (i.e. 90 days).

The two transactions can then be printed, and left to the inheritors.
The user can then have a reminder to check whether the transaction-id of the Alert transaction has been broadcasted - if so, it means that the papers have been breached. In this case, the user has enough days to use his master key to send a Cancellation transaction, moving his funds to a new address (thus invalidating the Recovery transaction).

This could also be useful for users that keep significant funds in memorized seed phrases, but also want to leave an emergency recovery option to a less-secret secondary wallet, just in case they forgot their seed phrases.

Please watch the video that I've made explaining which common inheritance-solutions exist today, and includes a demo of the timelock-recovery extension for Specter (and more technicalities, like a minimal amount of funds in the Alert transaction that go to anchor-addresses, so it could be boosted with CPFP).

If you don't have any objections, I'll be happy to start working on this feature (but I have to admit that I haven't developed in Java for many years).

[craigraw]

Thanks for presenting an interesting solution to the inheritance issue. You've already included in the video a good breakdown of the pros and cons of existing inheritance solutions, but I'd like to add two cons to this one:

1. The alert transaction links all UTXOs onchain, potentially destroying privacy (of course, that might be deemed acceptable for this situation).
2. Similarly, anyone discovering the physical copy of the alert transaction will be able to see the wallet balance and addresses in an unencrypted form.

No doubt you have already considered these, but I think they're worth mentioning.

I'd like to take some time to consider this solution against the miniscript based solutions, which are becoming more popular.

[oren-z0]

I agree that consolidation could cause privacy issues, but giving non-technical users a simple solution is more important at the moment (explaining the idea of anchor addresses is complicated enough...).
The fear of losing your keys or dying unexpectedly makes many Bitcoiners either share their seed+passphrase with less experienced people (inheritors), or worse - buy ETFs instead of actual Bitcoin!

Scripts are great, but I found that many Bitcoiners are terrified of transferring large amounts to new HW wallets or apps. That's why I want to implement this as a feature in existing desktop wallets.

There are also other warnings that users must notice: Spending any UTXO invalidates the Alert transaction, and newly received funds are not covered by the Alert & Recovery transactions. Maybe this could be solved with Covenants in the future. The step-by-step guide that I wrote for Specter explained this, and so will the guide that I'll write for Sparrow.

Thanks!