Limit wallet requirements to security requirements for now

[saivann]

As suggested on #704 , this pull request limits requirements to security requirements for now.

I think other types of requirements, for instance in this case protecting the network against certain form of abuse of the block chain, could be considered later if:

• There is enough agreement that suggested requirements are indeed considered abuse.
• There is enough indication that such abuses are becoming or will become problematic.
• There is enough indication that adopting these new requirements will be helpful (e.g. if block chain abusing features become popular enough, bitcoin.org would likely end up with a reduced wallet list without having much impact on the issue, making such requirement questionable).

[gmaxwell]

I don't think this is a great idea. We're free to consider on a case by case basis if a particular requirement is advisable or not; and the text invites arguing if some requirement is a "security" requirement or not.

For example, someone might argue that "The identity of CEOs and/or developers is public" is not a security requirement, or that "Allows backup of the wallet" isn't or that the use of a revision control system isn't. (I don't agree that they aren't but a credible argument could be made.)

The boundaries of security are often unclear. And even your example of "protecting the network against certain form of abuse" is very much a security concern e.g. if the network capacity is frivolously exhausted, all users are left more vulnerable to attack, suck trusting hosted wallets, etc. It may not be a concern for the whole user, but it can be a concern for the greater ecosystem.

Fortunately, wallet developers that are doing enough work to get listed based on the other criteria so far have tended to be clueful enough to behave responsibly by default; so we haven't had major problems with these kinds of issues, and I don't expect us to soon.

[luke-jr]

If issues ever became problematic, then it would be too late to really have any effect with bitcoin.org. It makes sense to wait to add policies until they're relevant (as would have been the case with the spam-encouraging one if Electrum wasn't reverting it), but to wait until it's futile (and promote things harmful to Bitcoin in the meantime) seems reckless.

[gmaxwell]

@luke-jr It would be preferable if it never seemed that threatening with delisting was a first step in resolving an issue. :)

(I realize you felt electrum was unresponsive after they previously didn't respond to your concerns about address reuse; but not everyone else has the same context.)

One reaction to that kind of aggressive approach is calls for narrowing the scope. So thats a cost you should have been considering. :)

[saivann]

Fair enough, let's not spend more time on this for now (I will close the pull request later today unless there is additional discussions ongoing)

FWIW, I think it is very helpful that many developers in this space are reasonably responsive and collaborative, and I wish we could work carefully to preserve this collaboration.

@luke-jr Despite that I disagreed in part with the approach taken, I really appreciate that you're monitoring and reporting these issues.

[harding]

ACK on closing.

Strong ACK on appreciating @luke-jr's contributions