Automatic cloud backup
Encrypted backup to a service, what it actually protects against, and the circular-dependency trap that makes a backup fail when it is needed.
Manual backup fails for a predictable group of people: the ones who will not write anything down. Automatic backup exists for them. Honestly put, it adds a dependency on a service in exchange for a large reduction in the chance of total loss. Done properly, the service holds only data it cannot read.
We suggest that for most people a lost phone is a likelier loss than a failed or dishonest provider. For an everyday wallet, that favours automatic backup. For savings it does not. See Wallet setups.
What goes to the service
Two different things, with different rules:
| What | Encrypted before leaving? | Where it should go |
|---|---|---|
| Key recovery material | Always | Only with the user's deliberate, separate consent |
| Wallet records | Always | Local by default, remote as an explained opt-in |
Wallet records are the bigger win and the lower risk. Backing them up continuously means a restored wallet knows which outputs are the user's, which on BSV a key restore alone cannot tell it. The wallet data format (BRC-38), with its encryption extension (BRC-39), is the portable form of exactly this, and a synchronisation format (BRC-40) covers keeping copies in step.
Key material is the sensitive one, and the one that is easiest to get wrong.
Do
Encrypt on the device, before anything is sent. The service should only ever hold a blob it cannot read.
Don't
Store the root private key on a remote service in a form the service can decrypt. That is custody, and it should be described as custody.
The circular-dependency trap
This is the failure that matters, and it is almost always designed in by accident.
A backup encrypted with a key kept in the phone's keychain is not a backup. A backup behind an account whose two-factor code arrives on the lost phone is not a backup. A backup in a password manager that was only installed on the lost phone is not a backup.
Every step that needs something which was only on that device fails exactly when the backup is needed.
Do
Walk the recovery path assuming the device is gone, not locked, and remove every step that needs something only that device had.
Testing it
Recovery is the only test that counts:
- Set up a wallet and let it back up.
- Wipe the device, or use a different one.
- Recover using only things the user could have from somewhere else: an email address, a password they remember, a share held by somebody else.
- Check the balance, the activity and any tokens all came back.
A product that has not done this does not know whether it has a backup feature. For the full drill, see Backups › Test recovery before launch.
Who holds the encryption key
Three workable answers, in increasing order of what the user has to manage:
- A password they remember. Simple, and the whole thing rests on a password people forget. Pair it with a recovery check the user can run any time.
- A share held elsewhere (BRC-140, BRC-154). The service holds the encrypted data, and the user or a third party holds a share. Neither alone is enough. Good for inheritance and for business controls.
- A hardware key or passkey. Strong, and only works for people who already carry one.
Don't
Derive the encryption key from something the provider also holds. If the provider can decrypt it, the user is not self-custodying and the screen should not say they are.
Choosing a provider
Do
Let users choose their provider, or run their own. A backup tied to one company is a backup with that company's lifespan.
Do
Support more than one location at once. Two independent copies is the point.
Do
Show when the last backup ran, on a screen the user sees often. A backup that silently stopped three months ago fails exactly when it is needed.
Don't
Turn remote storage on without saying so. It is a meaningful change in who can be compelled to hand over data, and it belongs to the user to decide.
What to say to users
Avoid "your wallet is backed up to the cloud", which sounds like photographs and implies someone can get it back for them. Say what is true:
Your wallet backup is encrypted on this phone before it is sent, so the service cannot read it. You will need your password to restore it, and nobody can reset that password for you.
Open questions
- How do users weigh losing a phone against a provider failing, and does the answer change with the balance?
Pros and cons
Pros
- Survives the common failure, which is a lost or broken phone.
- Records can be backed up continuously, which manual backup cannot do.
- No paper for the user to lose.
Cons
- Adds a service, a password and a recovery path, each of which can fail.
- The circular-dependency trap is easy to build and hard to notice.
- Encrypted data held by a provider can still be subpoenaed, lost or deleted.
Related
- Manual backup
- Backups: what a complete backup contains
- Daily spending wallet: automatic cloud backup
Written from: BRC-38, BRC-39, BRC-40, BRC-140, BRC-154.
Checklist
The rules on this page, in a form you can work through.
8 rules