Rethink the wallet listing criteria

[achow101]

I think the wallet listing criteria needs to be rethought and made stricter. Any changes to the criteria should also be reflected on the site immediately by delisting all wallets which fail to meet the new criteria.

I think we should not allow web wallets, and in general, wallets that do not allow users to access their private keys and rely on a central service in order to function. These wallets provide less security and privacy and go against the ideals of decentralization (as they are centralized services).

I think that we should also require all wallets that are listed to be open source software, not just have their source code available. The software should be licensed under an OSI approved license.

Thoughts?

[Mirobit]

I agree with @crwatkins that all bitcoin banks should be removed. Services that don't provide private keys to users should not be considered wallets. They can be listed on the Exchanges page.

I am not sure about removing Coinbase since they offer MultiSig Vault. But most users probably don't/won't use it.

I am fine with keeping keeping GreenAddress and co. I agree that they go against the ideals of decentralization but they can be more secure for inexperienced users through the use of 2FA than Core/Electrum. Also users can access their coins if they disappear.

[FrancisPouliot]

We can't just remove all the web wallets though.

Perhaps we should make a more fundemental distinctions between wallets and wallet services, or wallet-as-a-service businesses.

Wallets that don't allow users to access private keys should be removed entirely. There is no difference between a wallet that doesn't allow access to private keys and a bitcoin balance in an online poker account.

[luke-jr]

Why can't we just remove all the web wallets? IMO that would be a good idea...

Giving the users access to the private keys does not make a webwallet more secure, nor is it even a good idea (so long as users are trusting a website, best practices would be to use a shared wallets with hot/cold separation).

[alex-wilmer]

Shouldn't all the options be presented with their security caveats in plain view?

[FrancisPouliot]

@luke-jr the answer to your question is that these wallets do exist, and users will use them, a fact that we must acknowledge. Users will be looking for the reviews of those wallets, will probably end up on this site.

So if they can clearly see that these wallets are listed there, but in a separate category, with a risk warning for example, it's better than them not finding the review and going on another site.

[luke-jr]

@FrancisPouliot bitcoin.org already does not list wallets unless they meet a minimum criteria, since the page is seen as recommendations. What you're suggesting implies getting rid of that policy altogether. IMO if you'd like to promote the idea of a "not recommended wallet list" page, that should be a separate issue...

[achow101]

Bitcoin.org's Choose Your Wallet page is a list of recommended software, and is often used for pointing new users to a list of good, recommendable, wallets. We should not just list all wallets available and let the user decide as they may not know what any of the listed caveats mean. IMO the wallets listed on bitcoin.org should be wallets that you would be willing to recommend to a new user so the wallets listed must meet a specific criteria, one which we already have. I think that criteria needs to be strengthened though as there are wallets currently listed I wouldn't recommend but they still meet the criteria.

[Sjors]

@achow101 what is the rational for requiring a specific software license? From a security point of view, I can only see two relevant criteria:

1 - the code is visible
2 - you can reasonably verify the code shown is actually the code that's distributed

Especially that second criteria is not met by some wallets currently listed. I'm not aware of a mechanism to do that for iOs for instance, except by compiling it yourself using a developer license.

[Sjors]

In addition to source code being visible, you could require a certain level of review-ability. Not to pick on any wallet in particular, but the way Jaxx publishes their source code is utterly impractical to review. You could also require a certain level of actual review, or a certain minimum bug bounty level (see e.g. Parity multi-sig bug that stayed undetected for 7 months, despite that not being a web wallet and despite it being open source).

It would also be good to setup automatic monitoring for these wallets, to detect if a new version is released without a corresponding source code update (verifying the version number at minimum, but something like Gitian would be even better). E.g. Coinomi seems to have stopped publishing updates six months ago and I haven't seen anyone pointing that out yet.

As for @luke-jr suggestion: it would seem more consistent to exclude all wallets that rely on an external node. That leaves only SPV and full node wallets. If you're also worried about attacks through shipping malicious code to specific IP addresses, then you also need to delist any wallet that relies on an automatic software update mechanism (especially a mechanism built into the app, rather than at the OS level).

I personally think it's better to educate people and discuss the various drawbacks of each wallet type and perhaps even of each specific wallet, platform and method of installation. That doesn't preclude you form very prominently recommending one or two wallets at the top.

[Sjors]

Finally, another example of why education + suggestion is preferable, is someone in a country where running a bitcoin node is itself a crime, or even just used by law enforcement to narrow down the list of suspects. Especially if such a country also bans Tor and VPN. Or let's say a country where customs believes they have the right to open your laptop for inspection. That creates totally different trade-offs.

[crwatkins]

There have been no comments on this issue for a year. Since it was opened, we now require access to private keys (#1706) which addresses some subset of the above concerns (and the area that I was most concerned about). I suggest we close this issue and open new issues (or PRs) for any specific suggestions not relating to private key access.

[wbnns]

@crwatkins Ok, thanks. We can reopen if others feel additional discussion is needed.