BIP idea: Timelock-Recovery storage format

[orenz0]

After a short talk with achow101 during BTC++ Taiwan, I'm starting this thread to discuss whether my idea is BIP-worthy.

Motivation for Timelock-Recovery plans:
Storing seeds for recovery & inheritance is scary.
Pre-signed transactions to a secondary-wallet/custodian, are safer to handle and backup due to their immutability.
A single pre-signed transaction with a future nLocktime requires "renewal" when the nLocktime deadline is getting close, which could be annoying (i.e. if the seed is split over multiple geographic locations).
Covenants/Vaults are still being debated, and could scare less-technical Bitcoiners.

Solution:
Pre-signing a pair of transactions:

• Alert/Initiate Transaction: A consolidation transaction that keeps most funds on the original wallet (except for a minimal amount that goes to anchor-addresses, for CPFP acceleration)
  
• Recovery Transaction: A transaction that moves the Bitcoin from the consolidated UTXO to the secondary-wallet(s), with an nSequence relative-locktime that gives the user enough time to move the funds elsewhere (assuming they noticed that the Alert transaction was mined, and still have the seed or signed an alternative transaction in advance).
  

Similar to a single pre-signed transaction with a future nLocktime, Timelock-Recovery plans will not include new funds that are added to the wallet, and will be revoked even if a tiny amount is spent. This mechanism is intended for wallets that are going to remain untouched for a long time.

An example implementation can be found in the Timelock Recovery plugin that I've implemented for Electrum (merged since Electrum v4.6.0b1). Details and demo videos can be found at: https://timelockrecovery.com.
The plugin creates a UI for signing the two transactions, then saving them either in a PDF file (with detailed manual instructions for less-technological Bitcoiners how to broadcast them), or in a JSON format.

The BIP will be about the JSON format, which includes not only the raw transactions themselves, but also user-information (i.e. name, description, destination-labels, wallet-name, wallet-version), and data about the transactions (i.e. txids, amounts, fees, input-utxos, anchor-addresses, relative-locktime).
A standard JSON format will allow implementing a compatible feature on other wallets, as well as apps/servers for monitoring & initiating timelock-recovery plans - such as the one being developed by RITREK.com (disclosure: I'm one of RITREK's founders).

Let me know what you think!

Oren

[domob]

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.

[Elonn Wardd]

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 

[domob]

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 K1
• Spending by another private key K2, but relative time-locked to e.g. one year

Something 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.

[orenz0]

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 K1
• Spending by another private key K2, but relative time-locked to e.g. one year

Something 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.

[domob]

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.

[satscraper]

Liana Wallet can do the taproot script that you mentioned.

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.