UTXO based backups, an idea for bitcoin cold storage

Despite the many years that have passed since Bitcoin’s inception, we are still facing issues with key management. With this in mind, I would like to propose a new and novel way to ensure that cold storage funds can still be recovered.

Please note that this article is only a thought exercise and you should not take it as security advice.

Bitcoin, unlike ethereum, uses UTXO accounting to manage funds. Funds on the bitcoin network are calculated by how many unspent inputs your keys can unlock. 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.

With bitcoin, you can also sign an input over to an address but not broadcast the transaction, enabling someone to hold a signed check that can be held for later use. Unlike regular checks however, you have an actual cryptographic guarantee that the funds can be spent.

The Bitcoin network also supports a script called nLockTime, this script allows you to sign a transaction that is only valid once the specified time is reached. Such transactions will be rejected if they are broadcasted before the time specified.

This allows for some pretty neat use cases and is used for protocols like the lightning network.

So, with all these things in mind, let’s dive into how UTXO based cold storage recovery could work for UTXO based blockchains like Bitcoin.

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 whatever interval she thinks is appropriate. Alice then sends this signed transaction over to Bob or simply keeps it in her cloud storage provider like iCloud or Google Drive. Since this transaction is locked to Bob and confined 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 data with a cloud provider so that it never gets lost.

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 signed, time-locked transaction. This program could also notify Alice of when the transaction is close to being valid, allowing her to spend the inputs (invalidating the signed transaction) and repeat the process with a new timelock. Spending these inputs would prevent anyone from broadcasting an old signed transaction to the blockchain, even if the timelock requirement is satisfied.

If, on the other hand, Alice loses access to her keys, she can simply broadcast the transaction and send the funds to Bob, provided the timelock requirement has been met. Alice can then begin the process of re-obtaining the funds from Bob and sending them to a new cold storage address.

Note that Alice did not need to share the signed transaction with Bob in the first place and could simply store it on her own cloud provider. She would only need to broadcast this transaction in the event that she lost access to her keys and she can invalidate it at anytime by spending the inputs.

  • 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 signed transaction
  • Bob does not even need to receive the signed transaction, preventing him from broadcasting it in the event that Alice forgets to update the process but still has access to her keys
  • Alice’s keys are never exposed and can remain in cold storage
  • The signed transaction can be stored anywhere, even publicly
  • If Alice loses access to her keys, she can sweep the funds from her cold storage to Bob once the timelock is reached
  • The process can be easily repeated
  • Alice can revoke the validity of the signed 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
  • 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
  • This solution is only compatible with UTXO based cryptocurrencies (although it is possible to adapt the process for an account based cryptocurrency like Ethereum)
  • If Alice loses her keys, she must wait for the timelock to be reached and has to ensure that Bob is still trustworthy, not compromised and in possession of his key

So what do you think about this idea? leave your comments below.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store