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
