Adding a new choose-your-wallet "check" mark: deterministic / easy-to-back-up

[gurnec]

I'm sure everyone has their personal preference as to new "check"s that should be present in the choose-your-wallet page... the one I think is most important to add is an "ease-of-backup" check. Along with security issues (which are well addressed IMHO), backups (or lack thereof) have the greatest potential to lead to a loss of funds.

Are there any opinions on adding a new check to this page? I'd probably give wallets which are deterministic and which encourage backing up their master extended key / seed a "green", and all others an "orange". Any other thoughts?

[luke-jr]

Sounds like a good idea, but maybe it ought to cover automatic backups as well. Even deterministic wallets need regular backup for metadata (labels, etc).

[voisine]

Loss of metadata shouldn't lead to loss of funds though, so it's merely inconvenient.

[gurnec]

There are wallets that make backups easy even though they're still manual (e.g. Blockchain), and of course wallets that maintain key pools, but I think all of these alternatives become too complex to explain on a choose-your-first-wallet page, so I'm in favor of drawing a line at either deterministic-and-nagging or not.

[schildbach]

We already score deterministic wallets. So I think we shouldn't score that fact again.
Scoring a backup reminder, that's fine with me, but it just a tiny feature, probably not worth scoring.

[gurnec]

We already score deterministic wallets.

Do you mean privacyaddressreuse? That's almost the same as is-deterministic, but it differs for Bitcoin Core, Xapo, Coinbase, and Coinkite. But maybe I missed something?

I'm still in favor of making some sort of easy-backups check front and center for anyone new to Bitcoin, if for no better reason than to get people thinking about backups earlier rather than later.

[saivann]

I also considered this but my conclusion was this is too abstract. How do we define "ease-of-backup"? Scores need clear "yes/no" situations.

Additionally, IMO this falls into the users' responsibilities (which is why we have a warning disclaimer), allowing the user to backup their keys is a basic requirement.

I also don't feel like the "Backup" score would provide much key information and transparency to the user like other scores, and the description already doesn't have much space.

Some more details about other issues I had:

• When we take web wallets into account, the "backup wallet" concept doesn't work so well, the password of the account is what the user needs to backup and this might be confusing. We might also face issues with "account recovery" options, because they can be double-edged swords if they risk being used to hack accounts.
• There's a large diversity of backup scenarios which might have good and bad sides. Multisig wallets provide more complex backup plans, GreenAddress for example with their recovery emails, or BitGo with their 3nd key backup. Some wallets encourage users to keep an encrypted copy online, etc.
• All wallets can be backed up, but some can be backed up only once (HD wallets), but this criteria is indeed duplicating with the privacy score, and this might be more or less relevant in the near future as most if not all wallets move to HD wallets.

[gurnec]

How do we define "ease-of-backup"?

I concede that defining ease-of-backup is not straightforward.

Scores need clear "yes/no" situations.

I'm unconvinced of this. I think that if a consensus can be reached on a definition for ease-of-backup, it remains a worthwhile addition.

I also don't feel like the "Backup" score would provide much key information and transparency to the user like other scores,

Wallet backups are a confusing topic for beginners. HD wallet backups offer a fundamentally different (and typically much easier) backup procedure. I for one do consider this a key piece of information in choosing a wallet.

All wallets can be backed up, but some can be backed up only once (HD wallets), but this criteria is indeed duplicating with the privacy score

I disagree, and I gave four counterexamples in my previous post.

and this might be more or less relevant in the near future as most if not all wallets move to HD wallets.

I imagine the same, however I suspect it will be a long time before all of the currently listed wallets become HD.

Here's what I'd propose as a definition for ease-of-backup. If a consensus can't be reached on a definition, then it clearly has no place on the choose-your-wallet page.

• Easy backups: HD, with an unencrypted print-it-out or write-it-down option, where the backup alone is sufficient to restore funds.
• Possible but not necessarily easy: anything in between.
• Not possible: for cases where there's no ability to back up your private keys (e.g. Coinbase).

I don't claim that this definition is best, it's just a starting point for discussion. I also don't think that easy backups are better than the middle category due to security concerns, only that they are, well, easier.

With this definition, none of the online wallets qualify for easy... I'm not sure that's fair, but maybe it is. BitGo requires encryption (and obviously if you change your wallet password later, the printout's password no longer matches the online one). GreenAddress requires a recent recovery email (and recovery emails are not enabled by default). I don't think any other listed online wallet is HD.

Finally, I just want to point out that this isn't the first check whose definition isn't straightforward. The 2fa check is negative for Blockchain even though Blockchain does offer 2fa on login. It doesn't offer 2fa on a per-transaction basis however, and I'm guessing that this is the reason for it not qualifying as positive. I guess my point is that there's already some subjective decision-making on this page, and I don't have a problem with it, as long as their's consensus.

(wow this response is way to long...)

[schildbach]

I disagree on your "easy backups" definition. A single random key is just as easily backed up like an HD seed. Please don't tie the definition to a technical implementation alone.

If I'd define "easy" with my user hat on I would probably say:

• I need to go through backup setup only once. If possible, setup can of course happen automatically. But I doubt its possible, as for a remote backup you need some kind of encryption.
• After that, everything (balance + metadata) is backed up automatically and securely (remote!) and in all future (maybe excluding setting up additional accounts, if the software allows for that).
• Until it is set up, I get a reminder. But I'm not forced.
• If automatic backups fail, I get a warning.
• Restoring is easy as well. I'm not sure how to define that yet, but it's important.

[saivann]

Scores need clear "yes/no" situations.
I'm unconvinced of this. I think that if a consensus can be reached on a definition for ease-of-backup, it remains a worthwhile addition.

Maintainability matters a lot. Just look at the following questions:

Does this wallet require 2FA? (Yes/No)
Is this wallet easy to backup? (Yes/No)

The later is a matter of design and personal choice, you'll get different answers from different people, and most likely endless debates. We need to know exactly where is the line.

I'm still not convinced we're having a maintainable definition, as far as I'm concerned I'm not closed mind on this and I agree that backup is very important, yet this looks still too abstract for us to do a good job IMO. Also this might be a non-issue; all wallets seem to be moving toward HD and seem to be trying different wise backup dialogs / reminders.

[gurnec]

Please don't tie the definition to a technical implementation alone.

You're right. I was trying for a simpler definition, but a definition close to yours would work for me too.

I do have a few issues with it, though:

• I don't think metadata backups should be a requirement (but they're nice of course).
• A user shouldn't have to remember their wallet's encryption password in order to restore. Since backing up to a third party would require encryption, I imagine the user would need a printout or a written down mnemonic to perform a restore. I'm a bit biased on this one... let me know if you disagree.
• I disagree that restores need to be easy. I think backups need to be easy because people generally have very little motivation to perform them -- if they're not easy, in many cases they won't get done. As soon as a restore is required, a user suddenly has lots of motivation to figure it out. If this means seeking assistance, I'm fine with that. As long as a restore is feasible, that's good enough for me.

The definition of easy-to-backup is becoming increasingly complex... I'm beginning to think that saivann has been right all along (but I don't want to give up yet).

Also this might be a non-issue; all wallets seem to be moving toward HD and seem to be trying different wise backup dialogs / reminders.

I agree with everything else you've said except perhaps this. Using my (wildly inaccurate) crystal ball, I foresee that it will be many years before all listed wallets have an easy backup option. That's one reason why I think it's important to be front and center.

[harding]

@gurnec a problem with difficult restores is that they can't be easily tested to ensure that they work. When I was a sysadmin, we wouldn't consider a backup system complete until we'd done a successful test restore. (And then we'd also schedule periodic test restores to ensure the system kept functioning as expected.)

[saivann]

I agree with everything else you've said except perhaps this. Using my (wildly inaccurate) crystal ball, I foresee that it will be many years before all listed wallets have an easy backup option. That's one reason why I think it's important to be front and center.

As for going HD (and usually providing backup at setup time), I think Mycelium, Bitcoin Wallet by @schildbach, MultiBit all currently have alpha releases. KnC / BlockChain.info / Hive for Android all rely on Bitcoin Wallet by @schildbach , the only one I'm not aware about is Bitcoin Core.

@schildbach Just out of curiosity, would you be able to estimate how much time will be needed before your app switches to HD wallets (no promise, just to have an idea)?

[gurnec]

a problem with difficult restores is that they can't be easily tested to ensure that they work

But they still can be tested by the handful of people who choose to do so. Of course, I agree that simpler is better.

When I was a sysadmin,

Simple and speedy restores are very important whenever time is money, but I'd argue it's less important to an end-user who's just starting off with Bitcoin. Hopefully businesses won't be using the choose-your-wallet page as their sole source of wallet information...

If we're having trouble defining what an easy backup is, I suspect it will be even harder to define what an easy restore is. (That's no a reason to exclude easy restores as a requirement, I'm just pointing this out...)

[gurnec]

As for going HD (and usually providing backup at setup time), I think Mycelium, Bitcoin Wallet by @schildbach, MultiBit all currently have alpha releases. KnC / BlockChain.info / Hive for Android all rely on Bitcoin Wallet by @schildbach , the only one I'm not aware about is Bitcoin Core.

MultiBit seems to be getting very close. I didn't even know that Bitcoin Wallet was was working towards it (clearly my crystal ball has failed me, as well as my ability to simply look at their repo), that's great to hear! I don't think BlockChain uses Bitcoin Wallet, at the very least I'm sure its web implementation doesn't...

Even though HD is close to easy-to-backup, I wouldn't call either GreenAddress or BitGo easy-to-backup yet, despite that they're HD. Edited to add: and of course there are also the you-don't-own-your-keys wallets.

[schildbach]

@saivann It depends on when bitcoinj 0.12 gets released. Mike is working on the last piece that defines "HD". Then we need more testing. A couple of weeks I'd say. For Hive and hopefully KnC I'm confident they will follow soonish. Blockchain.info has deviated a lot since they branched off. If they are going the HD route, I'm sure they're doing their own thing.

@gurnec We're working on it since over a year: http://www.reddit.com/r/Bitcoin/comments/2edaem/bitcoin_wallet_40_alpha_1_hd_wallets_doesnt_reuse/
I'm not sure what you mean with "remembering the password". Of course you're always free to write it down…

[harding]

@gurnec I suppose this is a further illustration of the subjectivity of a backup score. My experience makes me feel like a test restore is part of a backup setup procedure, so setting up backups can't be easy unless restores are easy. However, I can understand if other people feel differently.

Trying to move this issue closer to conclusion, I think I'll cast my vote for "'easy' can't be objectively defined and so easy-to-backup shouldn't be a check."

Looking at the original post and all the discussion, I have no objection to indicating which wallets use deterministic key generation. It might be nice to have something like badges for wallets to indicate which support various optional BIPs, such as BIP32 and BIP39. (Or for wallets which ignore various standard BIPs, such as BC.i's long-standing lack of support for BIP16.)

[gurnec]

I'm not sure what you mean with "remembering the password".

Me either, that didn't make much sense. What it comes down to is I have a personal distaste for wallets which (1) recommend that you encrypt your wallet with a password, and then (2) offer no option to back up your keys unencrypted (BitGo does this for example). I was trying to make recovery-from-lost-encryption-passwords a requirement, but now I think it was a bit opinionated of me to want this.

[gurnec]

@harding

It might be nice to have something like badges for wallets to indicate which support various optional BIPs, such as BIP32 and BIP39.

It's nice and objective, but on the negative side would that mean adding technical jargon to a page which is impressively free of any today?

I think I'll cast my vote for "'easy' can't be objectively defined and so easy-to-backup shouldn't be a check."

At this point, I have to agree.

[saivann]

(Or for wallets which ignore various standard BIPs, such as BC.i's long-standing lack of support for BIP16.)

Or maybe at some point we could just stop promoting wallets which aren't supporting the most basic BIPs by making them a requirement (while giving them some time to catch up in case they're interested). @schildbach's answer regarding HD wallets is encouraging, I'm only concerned that Bitcoin Core will take more time to make the switch... Otherwise I think only BC.i doesn't appear to work on HD wallets.

[gurnec]

There's been no activity here in a while. Unless there are any objections, I intend to close this issue on Thursday evening with the consensus being that easy-to-backup is too difficult to define objectively. Thanks for the discussions, everyone.

Regarding @saivann's idea on removal of wallets that don't meet some bare minimum requirement: this could always be opened in a new issue, I for one would like to see this.

[saivann]

@gurnec I think we could re-discuss the "bare requirement" idea at some point when most wallets are HD. Regarding the backup score, yes maybe closing this issue would make sense at this point, it can be re-opened if someone has new ideas that could make something like this possible and address the issues that have been raised.