Introducing Recoverbull: a bitcoin wallet backup system using strong encryption, cloud storage and anonymous key servers

Bull Bitcoin is hyper-focused on a single objective: helping people become sovereign individuals by building tools that make Bitcoin self-custody easy.

Our mission is to make the experience of buying and selling Bitcoin, receiving and sending Bitcoin payments and storing Bitcoin for long-term savings using a non-custodial exchange and a self-custodial wallet as seamless and convenient as using custodial services like Coinbase.

We’ve identified three major pain points associated with Bitcoin self-custody:

1. To buy Bitcoin from a non-custodial exchange, users first need to create a self-custodial wallet. They need to use 2 different apps: an exchange app, and a wallet app. When they are buying Bitcoin, they may not even be aware of what a Bitcoin wallet is! Most people just see “number go up” and they want to invest in the price of Bitcoin.
2. Sending and receiving payments using the Bitcoin network can be expensive and slow. We all know that buying a coffee in person on-chain doesn’t make a lot of sense. Self-custodial Lightning Network wallets solve this, but have their own sets of problems.
3. It’s not easy to create a secure backup for a Bitcoin wallet. The most heart-breaking part of being a Bitcoin advocate is witnessing people lose their Bitcoin wallets and not having a backup or getting their funds stolen from an unsecure backup.

We’ve already solved the first two points by creating the BULL Wallet, which is seamlessly integrated with the Bull Bitcoin exchange and which uses state-of-the-art atomic swap technology to send and receive Lightning payments from a Liquid Network wallet.

So, how do we solve the problem of making sure people’s wallets are backed up securely? 

Bull Bitcoin philosophy

Before we start talking about our solution to the backup problem, let me outline our philosophy.

At Bull Bitcoin, we are builders and problem solvers. We recognize and accept wholeheartedly the issues and tradeoffs of the Bitcoin protocol. We cannot, and do not want to, change the way Bitcoin works. But we believe we can create innovative tools , apps and user experiences that will make using Bitcoin easier and safer for anyone.

It’s easy to take shortcuts and compromise on Bitcoin’s core cypherpunk values in order to “simplify” the Bitcoin user experience. That’s why most Bitcoin companies offer custodial services: no need to worry about self-custody problems if you don’t self-custody. What’s hard is achieving an amazing user experience while making as little compromise as possible.

Solving the backup problem: “you are screwed”

A lot of Bitcoiners will say “creating a backup is easy, all you have to do is write down your 12 word seed phrase”. We don’t disagree. But having helped tens of thousands of people use self-custodial Bitcoin apps, you get a more pragmatic perspective. Creating a backup is not as easy as that. 

Let me illustrate this with an example. I am orange-pilling a taxi driver, and I get him to download the Bull Bitcoin wallet. Before I feel comfortable that I’ve done my job as a Bitcoin educator, I need to make sure he has a proper backup. Here is what I will have to tell him:

• If you don’t do a backup and you lose your phone, you’re screwed.
• If you write down your backup on a piece of paper and you leave it in your pants pocket and it gets destroyed in the washing machine, you’re screwed. So better buy a metal backup plate.
• If you lose your phone and you can’t find your metal backup plate, you’re screwed. So you should probably buy two plates and store them in separate locations.
• If someone finds your backup metal plate, you’re screwed. So you need to add a BIP39 passphrase to your wallet.
• If your BIP39 passphrase is not strong enough, it will be easy to brute-forced, so if someone finds it, you’re still screwed. So use a strong, randomly generated passphrase.
• If you forget or lose your passphrase, you’re screwed. So keep a copy of your passphrase.
• If you keep a copy of a passphrase at the same place where you keep a copy of your backup, and someone finds it, you’re screwed. So you need 2 different hiding places: one for your backup, and one for your passphrase.
• And if you die…? That’s a whole other set of problems.

Let me be clear, it’s perfectly possible for the average person to do these things. But I’m sure you will agree that this is not the most ideal way to onboard a taxi driver to Bitcoin. For this reason, most people will just get the taxi driver to download Wallet of Satoshi, send him some sats, and hope in the future he learns to self-custody by himself. But what is most likely to happen is that this person will keep using wallet of satoshi forever (path dependency).

Existing solutions

There are tons of solutions to the backup problem. Here are some examples:

• You just don’t orange-pill people and you tell them if they can’t figure it out, Bitcoin is not for them.
• You tell people to buy suitcoins like $MSTR or ETFs like $IBIT from their brokerage accounts.
• You tell people to buy Bitcoin on Coinbase and just leave them there.
• You tell people to use a custodial wallet. 
• You tell people to use a professional custodian business like Onramp or Balance.
• You tell people to use collaborative multisig with key recovery services like Casa or Bitkey.
• You tell people to use a miniscript wallet with decaying or expanding multisig and time-locked recovery paths like Liania. (For the record, I think this solution is awesome).

But if you go back to the chart I posted above, none of these solutions have what I consider to be the right balance of tradeoffs between compromise and usability. Either they compromise too much, or they are too hard to use.All of this to say… my goal was to create a solution which has tradeoffs I think make it both usable while minimizing compromise. Let me tell you, that was not easy at all.

Nobody will argue with me that the user experience we’ve created is flawless. I know that many people will disagree with me about whether we compromised too much, but I am personally satisfied that we did the best we could. 

Building the solution: design goals

These are the goals I set for myself and our developer Azad:

• Bitcoins users are allowed to be uneducated, unwise, unmotivated, unskilled or incompetent. 
• Anonymity is inseparable from security. Any service or protocol that handles Bitcoin wallet backups should prioritize anonymity. Any information revealed by a Bitcoin user, including merely the fact that he owns Bitcoin, can be used against him by an attacker.
• A backup process should be easy to complete in less than 2 minutes.
• Backup should maintain its security and anonymity regardless of the location or device of the end user.
• Any service whose function is to facilitate Bitcoin wallet backups should avoid ever taking possession of user private keys, encrypted or otherwise, to avoid being classified as a money transmission service or virtual asset service provider.
• Services which facilitate backup recovery should be free (or extremely cheap). 
• Services that facilitate recovery should not have vendor lock-in and backups should be portable outside of the service provider’s application.
• Backup services should not require special hardware or software, and should leverage ubiquitous and widely available technologies.

Building the solution: Our premises

When building the solution, we worked using the following principles:

• A properly encrypted digital file is the safest way to protect a Bitcoin mnemonic from theft, if the encryption is strong enough to prevent brute-forcing and is performed in a device environment that is at least as secure as the one used for generating keys and signing transactions.
• Humans are bad at generating strong passwords. Any encryption key should be randomly generated with sufficient entropy to prevent brute force attacks.
• We cannot expect Bitcoin users to memorize randomly generated encryption keys with sufficient entropy.
• Humans are bad at backing up their data, both sensitive and non-sensitive.
• Password managers are, for most people, a convenient and secure way to backup their passwords. They are ubiquitous and part of people’s habits.
• Cloud storage providers are, for most people, the best and easiest way to backup data to protect against accidental loss. They are ubiquitous and part of people’s habits.
• Bitcoin users are more likely to be targeted by attackers trying to access their data than the average non-Bitcoin user and therefore must take their data security more seriously.

With that in mind, let me now present you our solution: Recoverbull

Recoverbull: How it works

The security model of the Recoverbull protocol relies on securely encrypting a wallet backup data with a strong encryption key that cannot be brute-forced. This encrypted data can be stored in a reliable but relatively insecure location, such as a cloud storage provider. 

The main problem with strong encryption of a mnemonic is of course that the entropy of the encryption key is such that it cannot be remembered. The risk is that it will be lost, and that the backup cannot be decrypted. For this reason, we propose a free, anonymous and accountless narrow-purpose key management service, the Key Server.

Authentication with the Key Server is performed by the user with a password. The user's responsibility is to remember or store a password. The protocol is designed so that this password should be memorable and can be very weak. We expect that users are likely to choose the same 6 digit PIN they use to unlock their mobile devices. Password bruteforcing is prevented by enforcing a strict limit at the Key Server level. 

To make it very simple, the end result is:

• The encrypted backup is hosted in the user’s cloud storage
• The encryption key is hosted by an anonymous server
• To fetch the encryption key, all you need is a simple PIN or password.

User anonymity is also a critical component of the security model. The key server should neither collect nor store any information that may be able to identify the user. In case the key server database is compromised, or in case the key server is malicious, any personal information could lead to targeted attacks against the user. Emails and phone numbers can be traced to the legal identity of an end-user, revealing that the end-user is a Bitcoin holder.

Step-by-step Recoverbull backup process

Step 1: we generated a backup key by deriving 256-bit entropy from the private key of the wallet using BIP85.

Step 2: we encrypt the wallet backup using the backup key we generated at step 1

Step 3: we create a backup file which includes the encrypted mnemonic (ciphertext) as well as the bip85 derivation path used to generate the encryption key, a randomly generated backup ID and randomly generated salt.

The result of this operation is that the encryption key and the backup file are created on the user’s device. These two pieces of information can be used to obtain the mnemonic. The important part then becomes where these data will be stored.

Step 4: the user will store the backup file wherever he wants. By default, we propose cloud storage providers such as Google Drive or Apple Cloud, as they are ubiquitous. However, the user can choose to save this file anywhere, whether it’s on another device or a self-hosted cloud storage service.

Step 5: the user is prompted to provide a password. The password can and should be low-entropy, because it should be memorable. The Bull Bitcoin implementation prevents the 1000 most common 6-digit PINs from being used as password, but there are no other requirements are necessary. When the user provides his password, the password is hashed with the salt that is found in the backup file in order to produce 2 keys: an authentication key and an encryption key.

Step 6: the newly derived encryption key is used to encrypt the backup key. In order for the backup key to be decrypted, someone would therefore need to know the user password as well as be in possession of the backup file (which contains the salt).

Step 7: the user’s wallet initiates a TOR client and connects to a Recoverbull server over TOR. It uploads to the Recoverbull server the encrypted backup key, and supplies the identifier (found in the backup file) as well as the authentication key (derived from the user password and the salt, also found in the backup file).

Step 8: the recoverbull server hashes the user’s Authentication key and Identifier to create a Key ID. The encrypted backup key is stored by the Recoverbull server and associated to the corresponding Key ID. It is important to note that the encrypted backup key is not associated to the identifier or to the authentication key in the server database, but to this key. The reason for this is that we don’t want the Recoverbull server to be able to know which encrypted backup key can unlock a specific backup file unless the user’s authentication key is supplied. In other words, this concept prevents the Recoverbull server from associating a backup file to an encrypted key unless both the backup file and the user’s password are provided. However, in order to be able to enforce rate-limiting (see step x) the Recoverbull server will keep the identifier in memory for the rate-limiting period of 24h.

At this point, the backup process is complete. The end result is that the user’s backup file is stored in an easily accessible location, presumably his hosted cloud storage provider. The encrypted backup key is stored by the Recoverbull server. This creates, in effect, a 2-of-2 backup scheme where 2 separately stored parts of the secret must be re-combined in addition to the user’s password to access the backup.

Step by step Recoverbull backup process

Step 1: the user must first fetch his backup file, and import it in the Recoverbull-compatible application (presumably, his Bull Bitcoin wallet).

Step 2: now that the client application has the backup file, the user provides his password. From the salt in the backup file and the user password, the app will recreate the encryption key and the authentication key that were originally created at step 5 of the backup process.

Step 3: the client app initiates the TOR connection to the Recoverbull server, provides the Identifier and the Authentication key, and requests the associated encrypted backup key. The Recoverbull server strictly enforces rate-limiting of 3 attempts per day, associated with a single identifier. This is why the Recoverbull server must keep the identifier in memory during the rate limiting period (in our implementation it is 24h). An attacker in possession of a backup file trying to bruteforce access to the recovery server to obtain the backup key would do so by generating multiple authentication keys from the salt located in the backup file. Rate-limiting ensures that this brute-forcing attack is probabilistically extremely unlikely to be successful.

Step 4: The Recoverbull server, having been provided the authentication key and the identifier, derives from these 2 elements the Key ID. If a Key ID is found, the Recoverbull servers knows that it can safely return the encrypted backup key to the client, because the only way it could have been able to generate this Key ID is if the client was in possession of both the backup file and the password.

Step 5: The client application now has the backup file, the encrypted backup key and the encryption key. It decrypts the encrypted backup key using the encryption key, and then it decrypts the encrypted mnemonic found in the backup file using the backup key.

⁠The result of this operation is that the client app now has the user’s wallet mnemonic backup, and it can restore the user’s Bitcoin wallet.

Security model review:

Now that we have a clear understanding of the Recoverbull process, let’s review the key components of the security model.

1. On a technical level, it is a 2-of-2 backup scheme where two pieces of data are required to recover a wallet: the backup file, and the backup key. Because the backup key is presumably stored on the key server, and because the key server requires an authentication key which is itself derived from a user password, it is in reality a 3-of-3 backup scheme, because unless the user has stored a copy of the backup key himself, his password will be necessary to perform a recovery. This is designed to prevent theft or unauthorized access to the backup.
2. The user relies on ubiquitous cloud storage services to store the backup file, and relies on a dedicated Recoverbull server to store the backup key. This is to prevent accidental loss of access to the backup.
3. The security model relies on the user taking responsibility only for memorizing his password. For this reason, the protocol is designed for very low-entropy passwords. The responsibility to store the other parts of the backup (the file and the key) are outsourced to external service providers.
4. The security model of the key server itself relies on rate-limiting requests by clients to obtain an encrypted backup key. This is to prevent attackers from getting unauthorized access to a user’s backup file and then obtaining the backup key.
5. The user remains at all times absolutely anonymous when it comes to the Recoverbull server. Not only the Recoverbull server does not have any identifying information on the user (not even an IP address!) but it doesn’t even have any information that can link a backup key to a backup file, unless the user password is provided. This is to mitigate and prevent law enforcement requests from forcing the Recoverbull server to hand over the backup key associated with a user. What it doesn’t know, it cannot share.
6. Finally, the Recoverbull server is also anonymous. Part of the reason the Recoverbull server runs exclusively over TOR is so that its operators cannot be identified. In the Bull Bitcoin wallet implementation, we provide a default Recoverbull server. This server is run by anonymous volunteers. Anybody can run a Recoverbull server. The Recoverbull server must be trusted not to be reliable and remain accessible at all times, and to not collude with cloud storage providers. Bull Bitcoin strongly believes the anonymous volunteers running the Recoverbull server currently suggested as default in the Bull Bitcoin wallet can be trusted for these 2 purposes. 

Threat model and catastrophic scenarios:

The following scenarios can lead to complete loss of access to a user's wallet:

• Loss: user loses access to both his device and to his Backup File, and he did not have a physical backup.
• Loss: user loses access to his device, and the Key Server is inaccessible, and he did not have a copy of the backup key, and he did not have a physical backup.
• Loss: user loses access to his device and to his password, and he did not have a copy of the backup key, and he did not have a physical backup.
• Theft: user's backup file is accessed by a malicious attacker and the attacker also knows the password.
• Theft: a malicious attacker gains access to a backup file and the Recoverbull server database is publicly leaked.
• Theft: the cloud storage provider is actively colluding with the Recoverbull server operator (or runs a honeypot Recoverbull server).
• Theft: the Recoverbull and the Cloud Storage Providers are both compelled by the same legal authority to give up their entire databases, and both decide to comply and turn over their entire databases.

What is the use case for Recoverbull?

Not a cold storage solution

• It is not an alternative to hardware wallets with proper physical backup
• It is not a secure long-term Bitcoin storage solution
• It is not an alternative to collaborative custody or miniscript-based multisignature wallets

It’s a hot wallet backup solution  

• It is an alternative to custodial Bitcoin wallets or exchange accounts
• It is an alternative to physical backups for hot wallets
• It is an alternative to BIP39 passphrases for physical backups

Recoverbull should be considered a temporary solution. The reason for that is that if the Recoverbull server that stores the keys disappears, the user will not be able to recover his Recoverbull backup unless he has a separate copy of the backup key. The rule of thumb is that you should use a Recoverbull backup for the same amounts that you are comfortable using with a custodial wallet or for a hot wallet on your phone. 

For developers

The Recoverbull client and server source codes are of course open-source. As reference implementation, you can look at the Bull Bitcoin wallet source code.

• Whitepaper: https://recoverbull.com/whitepaper
• Client: https://github.com/SatoshiPortal/recoverbull-client-dart
• Server: https://github.com/SatoshiPortal/recoverbull-server
• Bull Bitcoin wallet: https://github.com/SatoshiPortal/bullbitcoin-mobile/tree/develop
• Recoverbull website: https://recoverbull.com/