Had a quick chat with achow101 at BTC++ Taiwan, and I figured I’d kick off this thread to see if my idea is worth considering for a BIP.
Why Timelock-Recovery plans?
Storing recovery seeds and planning for inheritance can be really daunting. Pre-signed transactions to another wallet or custodian are easier to manage and back up because they can't be changed. But a single pre-signed transaction with a future nLocktime needs to be ‘renewed’ as the deadline approaches, which can be a hassle, especially if the seed is split up in different locations. Plus, covenants and vaults are still up for debate and might freak out some less tech-savvy Bitcoin users.
Here’s the proposal:
Let’s pre-sign two types of transactions:
1. Alert/Initiate Transaction: This one consolidates most of the funds in the original wallet, keeping just a small amount to send to anchor addresses for CPFP speedup.
2. Recovery Transaction: This is for moving Bitcoin from the consolidated UTXO to secondary wallets. It has a relative-locktime using nSequence, giving users enough time to transfer funds elsewhere if they notice the Alert transaction was confirmed and still hold the seed or have a signed alternative transaction ready.
Just like with a single pre-signed transaction with a future nLocktime, these Timelock-Recovery plans won't cover any new funds added to the wallet and will get canceled even if a small amount gets spent. This is meant for wallets that won’t be touched for a long time.
You can check out an example implementation in the Timelock Recovery plugin I made for Electrum.
This is actually close to an idea I had for setting up recovery on my own wallets (but not yet gotten around to do it). I think this setup with presigned transactions but in a way that leaking them is not critical if you are watching and have the original key is a pretty great way to handle recovery and inheritance planning with a limited risk by having those transactions out of your control (such as given to persons whom you trust but whose data security you do not 100% trust).
So yes, from my point of view, it would be great if something like this could be standardised and implemented externally. I would personally use it and it would reduce my risk in setting up those transactions manually with custom scripts.
I love how you think and I love the idea.
This will solve the problem of being scared of your family or loved once not having access to your wallet, when something bad happens to you.
My friend had an accident and dead and his family couldn't access his wallet till date.
With this the secondary key which is the family or loved once can access the wallet.
Dead or lost memory your family can still access your Bitcoin. Your effort can't be a waste Great news
For the record, my own plan for this was a bit different (on the technical details) than what you propose. My idea was to set up a taproot address X with two spending paths:
Default spending by my original private key K1Spending by another private key K2, but relative time-locked to e.g. one yearSomething like this descriptor: tr(K1,and_v(v:pk(K2),older(one year)))
Then I could create a pre-signed transaction spending each of the UTXOs in my cold wallet to X, and share the signed transaction together with K2 with the trusted person. Of course it needs some mechanism to pay for fees as well; I was thinking of using SIGHASH_SINGLE for this, but an anchor transaction as you propose makes also sense.
In case I disappear, they would broadcast the transaction, wait for a year, and then could unlock the coins with the time-locked spending path with K2. In case they lose the data to a third party, it would be enough for me to check my wallet once a year to notice that the funds have disappeared (sent to the address X), and then I could use the default spending path to recover them.
Liana Wallet can do the taproot script that you mentioned. Their recovery solution is very useful for businesses and individuals that move their funds frequently. For example you can set a hard 4/5 multisig (i.e. of company board members) to spend funds immediately, and a weaker 2/5 multisig to spend UTXOs after 300 days. Liana even gives you reminders to "renew" UTXOs that haven't been spent for a long time.
So yes, you could presign a single transaction to move your UTXOs to something like a Liana wallet, that your trusted person could access with K2 after one year, but you could access with K1 immediately (if the presigned transaction was broadcast unintentionally). However with a pair of presigned transactions you don't need to setup a second script-based multisig wallet, with the overhead of saving the descriptors and public-keys for a long time. Any hardware wallet can presign transactions with a custom nSequence without any multisig or custom script (unfortunately many hardware wallets don't show you the nSequence information).
Your suggestion could be interesting if K2 was handled by a custodian, if your heirs are technologically-challenged. You pay for a multisig-service and together you create a Bitcoin address that you can access immediately, and the custodian can access only after one year. Then you can presign a single transaction to that address instead of a pair, knowing that your heirs could contact the custodian after a year. However, from my experience at RITREK, custodial exchanges struggle to guarantee long-term key security for simple wallets, let alone the safekeeping of multisig wallet descriptors.
Regarding fees and SIGHASH_SINGLE, these could lead to disastrous mistakes if misused. Do common hardware wallets even let you sign transactions that are not SIGHASH_ALL? Signing two transactions for each UTXO separately could be useful for Bitcoiners that still accumulate funds on the same wallet, but my recommendation is just to use separate wallets - one big wallet that you don't intend to touch for many years, and a smaller wallet for short-term access - that losing its funds won't be life-devastating for you and your heirs. I like the Trezor UI that lets you separate "accounts" (different derivation paths), or you could use passphrases, etc.
I also recommend just putting a large fee on the presigned transactions. In the good scenario, the presigned transaction won't be broadcast anyway, and in the bad scenario you don't want to confuse your heirs with transaction acceleration.
Thanks for the pointer to Liana Wallet, that is interesting! In my specific case, I have my own offline wallet setup (not a hardware wallet) where I would do the signing, so the situation may be slightly different from a standard solution built into existing wallets. But in any case, I think it would be very useful to have a standardised (via BIP) way to represent such a mechanism and have it implemented in standard tools. That can only reduce potential mistakes made and also simplify life for heirs (mine and others) that deal with recovering such coins.
Yeah, you are correct. But Liana uses the hierarchy of primary and recovery keys at the script level which tightly binds the recovery path to Liana itself since Miniscript is still barely supported by other wallets. Your renewal approach on the other hand is more universal and can be applied virtually to any existing wallet. I like this.
By the way, the forum has the thread dedicated to Liana wallet.