Dark Wallet Certification

[hivewallet]

Ref: Let There Be Dark!

Greetings from Bitcoin Singapore!

Hive will be attending unSYSTEM's DarkWallet meeting in Milan on the week of the 24th. We propose that the outcome of this meeting be, at minimum, the establishment of a v1 "Dark Wallet Certification", a set of best-practice guidelines for wallets focused on decentralization and anonymity.

This topic is has been opened in order to get the community thinking about what exactly a "Dark Wallet" should be: We assume the use of Tor, CoinJoin, CoinSwap and other such developments. We assume the lack of centralized services wherever possible. We presume that we can evolve ideas about authentication (see the work of John Light, Joe Casico etc)... Still, our ignorance is vast and we would like to come armed at this meeting, with your feedback.

What ideas or thoughts do you all have?

[gmaxwell]

I've been thinking some time that it would be good to have a certification— or more than one— for wallets, as I've been pretty disappointed by some of the feature gaps in some of the popular tools, especially in areas related to privacy.

It might be good to have a list of criteria that a wallet should meet, with each one traceable to ensuring the tool preserves the users privacy, security, and autonomy.  I think that in some cases the criteria should mandate specific techniques, while in other cases it should just mandate the effect.

E.g. instead of requiring it to use CoinJoin (or any specific implementation), instead it could be that it make it convenient and inexpensive to transact in a way which provides at least plausible deny-ability about the common ownership of inputs or the specific sources/destinations of payments.

[hivewallet]

I've been thinking some time that it would be good to have a certification— or more than one— for wallets, as I've been pretty disappointed by some of the feature gaps in some of the popular tools, especially in areas related to privacy.

It might be good to have a list of criteria that a wallet should meet, with each one traceable to ensuring the tool preserves the users privacy, security, and autonomy.  I think that in some cases the criteria should mandate specific techniques, while in other cases it should just mandate the effect.

E.g. instead of requiring it to use CoinJoin (or any specific implementation), instead it could be that it make it convenient and inexpensive to transact in a way which provides at least plausible deny-ability about the common ownership of inputs or the specific sources/destinations of payments.

Agreed.

About the non-requirement, why not just have it target some specific goals and specific technologies/implementations under the "Dark Wallet" certification, and simply update the standard as better methods are discovered? That does nothing to stop other certifications from coming into being, after all.

[tgerring]

Piggybacking on gmaxwell's idea, perhaps we can come up with a list of DarkWallet expectations and keep a running list of who's implemented what, much like a feature compatibility matrix.

Maybe just surfacing the gaps in a very public way (wikis, websites, etc.) will help to create more awareness and the community will naturally gravitate towards those that implement a minimum feature set to ensure privacy, security, and usability.

[genjix]

Maybe Dark Wallet can be one project, but unSYSTEM (the organisation) can have a set of basic principles for wallet developers about what we are working for, some practical advice and guidelines about doing certain things. They are voluntary but if you want to be part of the community, well you should be respecting and working for the people. It'd be cool to have other projects come join unSYSTEM and help establish a support network for Bitcoin projects and cool initiatives.

[hivewallet]

If you want to build a single product called "Dark Wallet" under a specific umbrella, more power to you Amir. That said, there's a pretty good reason to split certification, product and organization: Developers may not agree with the politics (or anti-politics) of the organization, but still appreciate the features. Being monolithic in that respect will likely just end up alienating a lot of legitimate use cases.

[Ecurb123]

I'm going to try to make it for at least a couple days. Being this is such a long running meeting, is there any sort of agenda being drawn up?

[jedunnigan]

Someone's name needs to change. I like the idea of a standard vetted and approved by the community, but conflating the unSYSTEM project and the certification names is misleading and a bit odd.

[didjaydisteele]

Is this free?

[hivewallet]

Someone's name needs to change. I like the idea of a standard vetted and approved by the community, but conflating the unSYSTEM project and the certification names is misleading and a bit odd.

Let's call it a tentative name then. Any suggestions for the long-term one?

More importantly, does anyone have anything to contribute to the meat and fabric of this discussion? It would really be nice if Peter Todd and gmaxwell could speak up here with more leading direction.

[jedunnigan]

Yea sorry that was a pretty empty comment on my part. I'll think of a name today.

Well, I guess we can start a running list of features a wallet that meets the standards support out of the box:
Like you said, CoinJoin, CoinSwap, most of the features of Bitcoin OMG (Coin Control, gmaxwell's privacy enhancement, etc...), extended public keys/HD wallets, and others I don't have time to list right now... will come back later.

Like gmaxwell said, none of these things should be forced on the end user, but should be available at the very least.

Is this mainly to enable network-wide privacy or are we trying to enforce more feature rich wallets in general? or both

[corebob]

... We assume the lack of centralized services wherever possible...

What ideas or thoughts do you all have?

Can you, or anyone really, see a situation where this is not possible?

[Peter Todd]

Touching on gmaxwell's point about whether or not features should be forced, I think we can divide the features into two main categories:

• Individual protections: Anything where the strength of the protection is not dependent or is only "linearly" dependent on how many other people also use it. For instance local encryption of wallets, encryption of p2p communication channels, etc.
• Communal protections: Anything where the protection is made significantly stronger as more people use it. Examples include CoinJoin, CoinSwap and mix networks.

Now what really distinguishes those two situations is that for the former, whether or not everyone adopts the same standard doesn't matter all that much, so a certification should be about what goals were achieved, not how.

However with the latter, there are really good reasons to try to get as many users on the same underlying protocol. For instance with CoinJoin/CoinSwap, you want the anonymity set to be all Bitcoin users, not "recent versions of electrum". This is especially important because CoinJoin won't get used if it's not convenient - the more people using it, the faster a join can be arranged and the more likely a casual user who mainly just wants his transaction to go through will be protected.

That doesn't mean every CoinJoin implementation has to be the same, but I do think we should make sure we come up with a lowest-common-denominator form of CoinJoin that is reasonable for any implementation to support and participate in. In this case I think we want the standard to eventually specify that common denominator explicitly.

[hivewallet]

I'm going to try to make it for at least a couple days. Being this is such a long running meeting, is there any sort of agenda being drawn up?

That's precisely what we are trying to encourage here.

Is this free?

The meeting or the certification? They are both free/should be free, presumably.

[crazy_rabbit]

Who is going to implement certification? And check it? And enforce it? And Pay for it? Or is it just voluntary and you get to throw a gif up on your webpage that says your a member a-la Bitcoin foundation?

[moderate]

Who is going to implement certification? And check it? And enforce it? And Pay for it? Or is it just voluntary and you get to throw a gif up on your webpage that says your a member a-la Bitcoin foundation?

All idiotic questions, goes well along the idiotic topic's title.

What should be done instead is just create a page with the features expected for An (Vaporware) App With a Name I Like. Then if you make My App I Like Best with those features, you just say that you have all the features for that (Vaporware) App With a Name I Like with a reference to that page created previously.

After reading some of the comments here, I'm surprised that the bitcoin-qt client is still free and open source. Calling for certifications (even more than one, lol) is certainly a joke, a bad one.

[hivewallet]

Who is going to implement certification? And check it? And enforce it? And Pay for it? Or is it just voluntary and you get to throw a gif up on your webpage that says your a member a-la Bitcoin foundation?

Let's figure that out together. It will be discussed, so if you are not attending the Milan meeting and have some ideas, please throw them out here. What we can definitely tell you is that we would keep this as open and democratic as possible. Certification could be anointed by vote, or by self-appointment (with justification). Probably the latter is best, so we can spawn thousands of additional threads on bitcointalk where we bicker about this-or-that detail. Who knows.

All idiotic questions, goes well along the idiotic topic's title.

What should be done instead is just create a page with the features expected for An (Vaporware) App With a Name I Like. Then if you make My App I Like Best with those features, you just say that you have all the features for that (Vaporware) App With a Name I Like with a reference to that page created previously.

After reading some of the comments here, I'm surprised that the bitcoin-qt client is still free and open source. Calling for certifications (even more than one, lol) is certainly a joke, a bad one.

Are you interested in privacy, security and decentralization being a standard part of wallets? If so, please consider taking a less cynical attitude towards the proposal. It's understandable (especially lately) that there is a lot of fear and doubt lingering around, but on the other hand that's all the more reason to push forward. It may be that the initial attempt goes nowhere... But let's try.

And please see our comment above to crazy_rabbit. We don't yet know how this could be done without corruption in some respect, but openly discussing it without blind dismissal is surely the best way to figure that out, no?

*hug*

[moderate]

All idiotic questions, goes well along the idiotic topic's title.

What should be done instead is just create a page with the features expected for An (Vaporware) App With a Name I Like. Then if you make My App I Like Best with those features, you just say that you have all the features for that (Vaporware) App With a Name I Like with a reference to that page created previously.

After reading some of the comments here, I'm surprised that the bitcoin-qt client is still free and open source. Calling for certifications (even more than one, lol) is certainly a joke, a bad one.

Are you interested in privacy, security and decentralization being a standard part of wallets? If so, please consider taking a less cynical attitude towards the proposal. It's understandable (especially lately) that there is a lot of fear and doubt lingering around, but on the other hand that's all the more reason to push forward. It may be that the initial attempt goes nowhere... But let's try.

And why exactly do you believe certifications are the way to go here ? For this specifically I'm not taking into consideration any of the recent events, so you can scrap that from your line of thought towards me.

[gmaxwell]

Touching on gmaxwell's point about whether or not features should be forced, I think we can divide the features into two main categories:

• Individual protections: Anything where the strength of the protection is not dependent or is only "linearly" dependent on how many other people also use it. For instance local encryption of wallets, encryption of p2p communication channels, etc.
• Communal protections: Anything where the protection is made significantly stronger as more people use it. Examples include CoinJoin, CoinSwap and mix networks.

See also Eben's brilliant comments regarding privacy problems as an ecological disaster.

[tgerring]

And why exactly do you believe certifications are the way to go here ? For this specifically I'm not taking into consideration any of the recent events, so you can scrap that from your line of thought towards me.

In the end, "certifications" are a public knowledge campaign. How that's carried out remains to be seen, but I think we're all pretty open-minded here, so if you've got a more polished idea, we're all ears.