Despite the many years that have passed since Bitcoin’s inception, many holders still struggle with key management and recovery. With this in mind, I would like to propose a new and novel way to ensure that cold storage funds can be recovered in the event that you lose access to your keys.
Please note that this article is only a thought exercise, and you should not take it as security advice.
A quick recap on UTXOs
Bitcoin, unlike cryptocurrencies like ethereum, uses UTXOs instead of account balances. Your bitcoin balance is determined by the number of UTXOs that your private keys can spend. This is more akin to cash, whereby you could have a wallet that holds a 20, 50 and 100 dollar bill. If you were to spend one of these bills, you would have to use the whole note, and if the note exceeds the value of the payment due, you would receive change. Similarly, if the bill comes out to $150, you could spend both the 50 and 100 dollar bill and receive no change.
Bitcoin allows you to sign but not broadcast a transaction, allowing someone to hold on to the transaction, and keep it as a signed check, one that can be broadcast at a future date. Unlike regular checks that can bounce, signed Bitcoin transactions give you a cryptographic guarantee that the funds can be spent, provided that the inputs have not been consumed in another transaction.
Time locked inputs
The Bitcoin protocol supports a script called nLockTime, this script allows you to sign a transaction that is only valid once a specified time has reached, defined as either a unix timestamp or block number. Such transactions will be rejected if they are broadcasted before the time specified.
This allows for some pretty neat use cases, and enables protocols such as the Lightning Network.
UTXO based recovery
With all this in mind, let’s dive into how we could leverage time-locked transactions to backup funds.
In this example, we have two characters. Alice, the holder of the cold storage bitcoin, and Bob, the person who holds the key that will receive the funds from Alice, should she lose access to her keys.
Bob could also be Alice’s hot wallet key that she stores elsewhere, perhaps even on an online device or cloud provider
Alice signs a transaction containing all the inputs in her cold storage wallet over to Bob, with a timelock set to a future date. Alice then sends this signed transaction over to Bob, or simply keeps it in her possession. Since this transaction is locked to Bob and constrained by a timelock, it does not need to be hidden and is therefore safe in the event that an attacker gains access to the data. This allows Alice to store the transaction data online.
A simple software program could then be designed to watch these inputs, and send out a notification to Alice in the event that they are spent, invalidating the time-locked transaction. This program could also notify Alice of when the transaction is close to being valid, allowing her to spend the inputs and repeat the process with a new timelock. Spending these inputs would invalidate the time-locked transaction and prevent it from being spent, even if the time-lock condition has been met.
If, on the other hand, Alice loses access to her keys, she can simply broadcast the transaction when the timelock condition has been met and recover the funds from Bob.
The advantages
- Bob is unable to access the funds before the transaction is valid
- An attacker is unable to gain access to the funds by discovering the transaction
- Bob does not even need to receive the transaction data, preventing him from broadcasting it in the event that Alice forgets to invalidate the transaction before the time condition is met
- Alice’s keys are never exposed and can remain in cold storage
- The transaction data is not sensitive
- If Alice loses access to her keys, she can sweep the funds from her cold storage to Bob once the time condition is met
- The process can be easily repeated
- Alice can revoke the validity of the transaction at anytime
- Works well for people who do not typically spend their cold storage funds
- There can be multiple “Bobs” with different parameters
- Compatible with hardware wallets like Trezor, which could sign new transactions each time the hardware wallet is used
The disadvantages
- If Alice wants to spend any of the inputs, it will invalidate the signed transaction and she will have to repeat the process
- The process has to be redone before the timelock is reached & Alice must consume the inputs to prevent an old signed transaction from becoming valid
- If Alice loses her keys, she must wait for the timelock to be reached and has to ensure that Bob is not compromised
If this article has piqued your interested, check out my prototype by clicking here.
What do you think about this idea? leave your comments below.
