Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin Request: Timelock Recovery #9414

Open
oren-z0 opened this issue Jan 9, 2025 · 2 comments
Open

Plugin Request: Timelock Recovery #9414

oren-z0 opened this issue Jan 9, 2025 · 2 comments

Comments

@oren-z0
Copy link

oren-z0 commented Jan 9, 2025

I want to implement a "Timelock Recovery" feature for Electrum, 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 there are no objections, I'll be happy to start working on this plugin.

@ecdsa
Copy link
Member

ecdsa commented Jan 11, 2025

I think this kind of plugin would be welcome. It is not the first time it gets proposed.

Notes:

  • the second transaction sends funds to an address with a script of the type (pubkey_wallet OR (pubkey_heir AND CSV))
  • the plugin should upload both transactions to a cloud storage every time the wallet broadcasts a new transaction.
  • for cloud storage, transactions could be encrypted with pubkey_heir
  • nostr could be used as cloud storage. not sure how reliable that would be :-)

@oren-z0
Copy link
Author

oren-z0 commented Jan 15, 2025

Thanks for the review.

  • the second transaction sends funds to an address with a script of the type (pubkey_wallet OR (pubkey_heir AND CSV))

I don't understand in which scenario the second Recovery transaction sends funds to a script. It's simply a transaction that happens to have nSequence of X days pointing to the first Alert transaction, signed in advance and saved on a USB stick and/or printed on paper.

I want to avoid using scripts and multisig as much as possible, and to implement this feature in wallets that do not support scripts. Non-technical Bitcoiners who have large funds are terrified of switching to a new wallet.

  • the plugin should upload both transactions to a cloud storage every time the wallet broadcasts a new transaction.

If a user spends daily from some wallet, it means he has easy access to the keys, which means he shouldn't be storing large amounts on this wallet anyway.

This feature is intended for ultra-cold retirement wallet of funds that were accumulated over years, with a very secret passphrase.

For day-to-day activity you can simply use a less-secret cold wallet - still using a HW wallet, but a copy of the seed could be given and stored by your loved ones.

Saying that - it would be nice if you could add funds to your retirement wallet in a way that it would be automatically recoverable (with a timelock-based contract) - without having to access your very-secret retirement wallet seed & passphrase. Unfortunately Bitcoin's UTXO model doesn't allow that, and new UTXOs will not be covered by the Alert transaction (and obviously not by the following Recovery transaction).

A user that accumulates more funds that he wants to protect in an ultra-cold wallet, could create another ultra-cold wallet with another timelock-recovery plan. For example, the wallets could have the same seed with different passphrases: "".

Maybe in the future smarter solutions could be built with Covenants. At the moment I'm saddened to see non-technical Bitcoiners terrified of a situation where they die unexpectedly or lose their backups, and their loved ones fail to find the seed/passphrase to recover the funds. On the other side they are also afraid of having too many backups that give immediate access to the funds. They simply sell significant portions of their Bitcoin and buy ETFs...

  • for cloud storage, transactions could be encrypted with pubkey_heir
  • nostr could be used as cloud storage. not sure how reliable that would be :-)

The extension that I developed for Specter generates PDF files with explanations to the heirs and QR codes of the Alert and Recovery transactions. It would be easier to zip and encrypt the files than have them recoverable using the pubket_heir.

But you could simply print them. Except for privacy issues, if somebody finds the papers and broadcast the Alert transaction then:
a. You still have enough time (90 days) to recover the funds.
b. The thief can't change the final destination of the funds - if he also broadcasts the recovery transaction, the funds will reach the heir's wallet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants