Myth: the Payment Protocol is bad for privacy

[Mike Hearn]

CA's are "funded by their users"? How so?

Er, they're funded by the people who buy certificates, i.e. their users. I know how CAs work thanks.

Tor is more "centralized" than CA's?

Just numerically, this is true. There are 7 directory authorities that matter in Tor, vs over 100 certificate authorities.

The claim that Tor is "funded" by the US government is pretty far out there - I would like to see more detailed evidence for such claims. Here is a list of sponsors: https://www.torproject.org/about/sponsors.html.en

This is a widely known fact, you could verify it by just reading the Tor wikipedia page. But here's some links to save you a few clicks:

http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/06/the-feds-pays-for-60-percent-of-tors-development-can-users-trust-it/
http://www.reddit.com/r/TOR/comments/1cq46y/til_80_of_tors_annual_budget_comes_directly_from/

But I'm not sure it's worth arguing with you, seeing as you think Bitcoin is related to Chaumian e-cash (they have no technical relationship at all beyond both being systems for electronic money).

[benjyz]

CA's are "funded by their users"? How so?

Er, they're funded by the people who buy certificates, i.e. their users. I know how CAs work thanks.

Just numerically, this is true. There are 7 directory authorities that matter in Tor, vs over 100 certificate authorities.

CA's are not independent actors. There is 1 (one) root for the Internet's DNS. What any user thinks about how the DNS performs is completely irrelevant. The DNS is controlled by ICANN and various corporations with some interference of governments. If I don't like how the system works there is nothing I can do. There is no feedback from users, other than through corrupted channels. In Namecoin users can suggest changes. It solves the problem of key storage, but unfortunately not the problem of key <> identity assignment. The original BitDNS discussion contained some interesting material on the subject.

If I'm following you correctly, you think that there should be no courts because they can't help in all disputes?  That every transaction should be spelled out in complete detail, even though it is pointless because neither party needs to follow it?

Well, there is a tension between those who want to have a Bitcoin system which operates above the law (darkmarkets) and those who want to integrate it with law (US law, I presume). I don't have an opinion, but one should recognize what this is about. One can start with the simple question what actually happens if two people transact on a public network with untraceable cash. What language does one use to describe the process ("merchant", "customer"), what is the role of intermediaries of all sorts (courts, law enforcement, transportation systems, etc.). I believe it's impossible to make any sense of this by focusing on "technical" issues alone. People on the Bitcoin dev list actually believe that economics is off-topic. Well, that leads to pretty strange and unproductive discussions.

[Gavin Andresen]

In order to acquire a certificate (which you need to sign the payment requests with), you must leave your personal details at a CA.
Your full name, your email, where you live, even your phone number.

You are going back on my ignore list, because you have no idea what you are talking about.

Maybe if I use simple, easy-to-follow steps I can convince you that you are wrong:

1.  Copy and paste this URL into your web browser:
  http://www.comodo.com/home/email-security/free-email-certificate.php

2. Click on the "Free email certificate: sign up now" button (the big orange one).

3. Enter whatever name you like, and a valid email address (an anonymous one, if you like) and a revocation password.

I just used "knownothingtroll@mailinator.com" to make sure it actually does work to give a fake name, anonymous email address (and no address or phone number).

Done deal, you've now got a certificate-authority-signed X.509 certificate for an anonymous email address that you can use for the payment protocol.

That wasn't so hard, was it?

[piotr_n]

In order to acquire a certificate (which you need to sign the payment requests with), you must leave your personal details at a CA.
Your full name, your email, where you live, even your phone number.

You are going back on my ignore list, because you have no idea what you are talking about.

Is that supposed to be a punishement?
If so, please be informed that you have been on my dicklist for like years already - never removed, not even planed.
But your posts don't scare me, so I have no reasons to hide them from reading - some of them are actually quite entertaining.

Maybe if I use simple, easy-to-follow steps I can convince you that you are wrong:

1.  Copy and paste this URL into your web browser:
  http://www.comodo.com/home/email-security/free-email-certificate.php

2. Click on the "Free email certificate: sign up now" button (the big orange one).

3. Enter whatever name you like, and a valid email address (an anonymous one, if you like) and a revocation password.

I just used "knownothingtroll@mailinator.com" to make sure it actually does work to give a fake name, anonymous email address (and no address or phone number).

Done deal, you've now got a certificate-authority-signed X.509 certificate for an anonymous email address that you can use for the payment protocol.

That wasn't so hard, was it?

Wow - now you really assured all of us, what a great security you managed to develop for the comminuity during these couple of years of your intense work.
Man, you are a genius. Whenever I will need a real expert on IT security, now I know where to find one
You and Mike - he is another security expert: whenever NSA breaks his security, he says loudly: fuck you NSA!
It is definitely the kind of security experts that bitcoin development needs, isn't it?
You guys clearly identify all the possible points of failure and address them in the most efficient way; usually through deeper integration with openssl, or another useless lib, like protobufs.

Joking aside.
To those who don't ignore me, if you don't mind me asking:
Now, knowing how "simple" it is to create a "secured" certificate, are you seriously going to trust this payment system?
Because apparently, as Gavin has just explained, the entire payment system comes down to the security of an email address.
What they have done is just replacing the original satoshi's system where you could do MITM attacks on the IP end, to a system where you just need to attack an email address.
And you don't need to be a security genius to know that the later is often even easier to conduct.
But hey, if someone steals you money using the secure payment protocol, at least you will have a receipt

From other interesting facts:
 * satoshi needed like a month to implement his system, while these geniuses needed years.
 * satoshi quickly realized that his system wasn't secured and just abandoned it. these guys are too proud for it and are going to defend it as long as they can, using all kind of silly propaganda.

I mean, lets face it: "Myth: the Payment Protocol is bad for privacy" - this is a typical topic template for a propaganda content.
I wasn't born yesterday and I know very well what propaganda looks like.
What I don't know though is: who pays for it? Obviously they won't say and it's going to come down to my tinfoil hat again.

[Gavin Andresen]

There's a real debate to be had; name calling just makes it impossible.

That is like 9/11 conspiracy theorists saying "there is a real debate to be had!"  ... after they repeatedly fail to listen to rational arguments ("Jet Fuel doesn't burn that hot! It cannot melt steel!" ... after being patiently told about the physics of furnaces: burning in a heat-trapping chamber).

I still haven't heard any rational arguments on how the payment protocol is worse for privacy. If piotr_n makes one, please let me know.

[piotr_n]

There's a real debate to be had; name calling just makes it impossible.

That is like 9/11 conspiracy theorists saying "there is a real debate to be had!"  ... after they repeatedly fail to listen to rational arguments ("Jet Fuel doesn't burn that hot! It cannot melt steel!" ... after being patiently told about the physics of furnaces: burning in a heat-trapping chamber).

I still haven't heard any rational arguments on how the payment protocol is worse for privacy. If piotr_n makes one, please let me know.

Sure: conspiracy theorists blew up three WTC towers into pieces in 2001, just to blame it on the government.
And in 2014 the same conspiracy theorists try to break Bitcoin by not embracing the new payment protocol and speaking against increasing the block size, in favor of off-chain transactions.
It's all because we "repeatedly fail to listen to rational arguments"... and our arguments are obviously never rational, so it is completely fine to not listen to them.

Do we really need to call this guy a lead bitcoin developer? Because it seems like an insult for an actual bitcoin developers.
If he doesn't understand that gasoline has no potential to blow up buildings into pieces, then he doesn't even deserve to be called an engineer.
Unless in America you have different laws of physics. Or different criteria to become an engineer...

What is the Chief Scientist doing about our outrageous conspiracy theories, concerning his biased involvement in bitcoin development?
Just as every professional media puppet, he is debunking myths - that is his way of presenting "rational arguments".

How can you trust such a guy to develop a bitcoin wallet for you?
A wallet that should be able to resist the government's pressure!
If anyone can be forced or otherwise corrupt to put a backdoor into software, these kind of people are the first candidates.
Be careful trusting him - he is obviously not a honest person. He clearly acts like this lady: https://www.youtube.com/watch?v=NOnwdmpButo
States something like it was a fact, but when confronted, just does the standard "I think I already answered this question, we are ready to move to another topic".
Don't you see it?

[kjj]

There's a real debate to be had; name calling just makes it impossible.

That is like 9/11 conspiracy theorists saying "there is a real debate to be had!"  ... after they repeatedly fail to listen to rational arguments ("Jet Fuel doesn't burn that hot! It cannot melt steel!" ... after being patiently told about the physics of furnaces: burning in a heat-trapping chamber).

I still haven't heard any rational arguments on how the payment protocol is worse for privacy. If piotr_n makes one, please let me know.

Sure: conspiracy theorists blew up three WTC towers into pieces in 2001, just to blame it on the government.
And in 2014 the same conspiracy theorists try to break Bitcoin by not embracing the new payment protocol and speaking against increasing the block size, in favor of off-chain transactions.
It's all because we "repeatedly fail to listen to rational arguments"... and our arguments are obviously never rational, so it is completely fine to not listen to them.

Do we really need to call this guy a lead bitcoin developer? Because it seems like an insult for an actual bitcoin developers.
If he doesn't understand that gasoline has no potential to blow up buildings into pieces, then he doesn't even deserve to be called an engineer.
Unless in America you have different laws of physics. Or different criteria to become an engineer...

Wow.  I thought he was just using a clever analogy, but it appears the arrow hit the mark anyway.  Do you have any opinions on the moon landing?

[piotr_n]

I have option on many things, but all of them would be off topic, except the one that some of you guys serve us a cheap propaganda in this topic. Seriously, don't you see it?
As for the other things I know, knowledge is power, so don't think my friend that I will just share mine with you for free.

So it doesn't bother you that the payment protocol that took you few years to develop guarantees that a guy who had an access to your email address at any time in past can just issue payment requests in your name?
You still think it's great and people should use it for making sure that they send coins to the right address?
Well, I don't

[kjj]

I have option on many things, but all of them would be off topic, except the one that some of you guys serve us a cheap propaganda in this topic. Seriously, don't you see it?
As for the other things I know, knowledge is power, so don't think my friend that I will just share mine with you for free.

So it doesn't bother you that the payment protocol that took you few years to develop guarantees that a guy who had an access to your email address at time in past can just issue payment requests in your name?
You still think it's great and people should use it for making sure that they send coins to the right address?
Well, I don't

Well, I certainly do see plenty of cheap propaganda hereabouts, but not coming from the side you seem to think it is coming from.  So far, every objection against the payment protocol that I've seen has been emotional.  With the exception of your current post, the one quoted above.

I have two objections to your objection.  First, you are throwing the baby out with the bath water.  Having an optional easy to use signed invoice is a vast improvement over the alternatives.  Note that I said "easy to use", which disqualifies PGP, and probably bitcoin message signing.

Second, you don't even need to lose control of your email account for someone to create a bogus PGP key in your name.

[piotr_n]

You and me perceive security differently.
Digital identity is something that you need to establish - gpg solution is very specific about it. But also provides a very useful web of trust.
Your solution is for kids - it isn't a security.
Your argument is that I first need to send my pgp key via email anyway.
You obviously don't understand what it is all about.
No sane pgp user will trust a key that he received only by email - and the system informs a user about it, all the time.
What you have made is a solution that you advertise as something that can verify identity, while in fact it doesn't seem to be more secure than just exchanging plain bitcoin addresses by email.
You've made a great job hiding from a user a misery of your lame security feature.
It is not a secured payment system - deal with it.
And it does not increase privacy - sooner endangers it.

[phelix]

Maybe if I use simple, easy-to-follow steps I can convince you that you are wrong:

1.  Copy and paste this URL into your web browser:
  http://www.comodo.com/home/email-security/free-email-certificate.php

2. Click on the "Free email certificate: sign up now" button (the big orange one).

3. Enter whatever name you like, and a valid email address (an anonymous one, if you like) and a revocation password.

I just used "knownothingtroll@mailinator.com" to make sure it actually does work to give a fake name, anonymous email address (and no address or phone number).

Done deal, you've now got a certificate-authority-signed X.509 certificate for an anonymous email address that you can use for the payment protocol.

That wasn't so hard, was it?

Now, knowing how "simple" it is to create a "secured" certificate, are you seriously going to trust this payment system?
Because apparently, as Gavin has just explained, the entire payment system comes down to the security of an email address.

He's got a point there.

@piotr: If you were more polite people might listen more to what you say.

[justusranvier]

Nobody wants to talk about making life easier for graph analysis, apparently.

[piotr_n]

@phelix, Like I cared if they listen.
If I were more polite, I would not have caused Gavin to write a walkthrough on how to break his system

[Carlton Banks]

Sigh. Much as I find marcus' input valuable on this forum, Gavin's post calls it correct.

The payment protocol protects you against common hackers performing known MITM atatcks, but it doesn't pretend to be a solution to CA's submitting to government agencies, that's the size of it. Just because the bitcoin payment address and the personal details of the customer are exchanged in the same SSL session does not mean the payment protocol is sending those personal details to the Illuminati. This is pretty plain once you've become familiarised with the two systems. The payment protocol doesn't handle that data, but the merchant does in the same encrypted SSL session (and the merchant site will obviously do that whether you're using the PP or not, unless you're using a merchant with no SSL certificate at all).

I think everyone who advocates payments protocol has acknowledged these weaknesses, and they have variously expressed a desire for an improved identity system for authenticating website sessions. Some decentralised design is possible, but it's said to be a difficult problem to solve in all it's nuances. I predict it will happen as a result of building an additional protocol on top of the new decentralised data storage technologies that are currently launching.

[justusranvier]

Sigh. Much as I find marcus' input valuable on this forum, Gavin's post calls it correct.

The payment protocol protects you against common hackers performing known MITM atatcks, but it doesn't pretend to be a solution to CA's submitting to government agencies, that's the size of it. Just because the bitcoin payment address and the personal details of the customer are exchanged in the same SSL session does not mean the payment protocol is sending those personal details to the Illuminati. This is pretty plain once you've become familiarised with the two systems. The payment protocol doesn't handle that data, but the merchant does in the same encrypted SSL session (and the merchant site will obviously do that whether you're using the PP or not, unless you're using a merchant with no SSL certificate at all).

I think everyone who advocates payments protocol has acknowledged these weaknesses, and they have variously expressed a desire for an improved identity system for authenticating website sessions. Some decentralised design is possible, but it's said to be a difficult problem to solve in all it's nuances. I predict it will happen as a result of building an additional protocol on top of the new decentralised data storage technologies that are currently launching.

Again, all that misses the point - it's not about identity or MITM attacks.

The payment protocol cements into place privacy-hostile behaviour in a way that will make it increasingly difficult to change in the future. Merge avoidance it the best practical way to protect users from graph analysis, and the only way to ensure merge avoidance in all cases is if the payers always have the option to split their send into multiple transactions to different addresses.

Merchants can optionally allow payers to request additional outputs, but since it's optional it means that they could deny the requests. They'd have a plausible excuse for denying this, since there currently isn't any good support for HD wallets. Good thing the payment protocol was implemented before BIP32.

[gweedo]

Guys I been trying to fight this fight for 2 years. We all know payment protocol isn't going to work, and companies like bitpay/coinbase are just going to force it upon the newbies until it works.

So lets stop yelling at Gavin, who obviously just wants to play dress up and work on his beard...

AND LETS GET A FORK INTO THE BITCOIND/BITCOIN-QT I am more than ready to help either thru funding or dedicating what is left of my time to making this work. I can't do it myself thou.

[Carlton Banks]

Again, all that misses the point - it's not about identity or MITM attacks.

The payment protocol cements into place privacy-hostile behaviour in a way that will make it increasingly difficult to change in the future. Merge avoidance it the best practical way to protect users from graph analysis, and the only way to ensure merge avoidance in all cases is if the payers always have the option to split their send into multiple transactions to different addresses.

Merchants can optionally allow payers to request additional outputs, but since it's optional it means that they could deny the requests. They'd have a plausible excuse for denying this, since there currently isn't any good support for HD wallets. Good thing the payment protocol was implemented before BIP32.

Well, that's not the point that the most vociferous naysayers have been trying to make, but I accept it.

I don't think it's a particularly overt oversight in the design of BIP70. The emphasis in the design outline (as described by Gavin, Mike & Jeff) seemed to be to solve only the identity/MITM issue for payment protocol v1.0. Neither coin control or hierarchical/deterministic wallets existed in a standard wallet implementation while BIP70 was being designed and written. I think it's only fair to defer complaints about controlling the number of payment outputs/addresses until more of the dust has settled with these two features (arguably only the Trezor has an actual BIP32 implementation right now, so there is no viable software to serve BIP32 address chains to a consumer anyway).

And so far, I've never experienced a merchant that allows the user to specify the number of payment addresses I would like. If the developers of wallet software haven't even implemented the features to both spark contemplation of the issue and encourage a culture of merge avoidance features, then I don't expect merchants to understand the issue right now. But you are right to bring this up, as that will happen in time.

[Peter Todd]

Tor is more "centralized" than CA's?

Just numerically, this is true. There are 7 directory authorities that matter in Tor, vs over 100 certificate authorities.

In the CA system any one of those 100 certificate authorities can break your security - 100 single points of failure. In Tor that's just 7 single points of failure, and IIRC Tor does have a n of m scheme for directory authorities.

As the experts have known for years, you can do even worse than centralization, significantly worse: you can have numerous points of failure distributed around the world where failure of any one breaks your security. The certificate authority system is exactly that.

[Mike Hearn]

The idea that the payment protocol doesn't support merge avoidance is bizarre, given that I coined the term merge avoidance in an article explaining how BIP 70 was already designed to support it, back in 2012. Being told that my own design doesn't support my own ideas - huh!

BIP 70 supports merge avoidance by allowing clients to submit multiple transactions to satisfy the requested set of outputs. This lets a client balance the outputs it has in its wallet with the outputs being requested by the payee, and the payee can try to ensure a decent distribution of outputs in its wallet by asking for them as appropriate.

BIP 70 does not require wallets to support generation of arbitrary numbers of outputs, because the client doesn't know what denominations the payee would need, and allowing the payee to specify the outputs precisely reduces the possibility for "dick moves" like a client paying the requested amount using an enormous number of tiny outputs, which would pointlessly force the recipient to pay extra fees when it isn't necessary. The payee is in the best position to know what kind of outputs it wants, not the payer.

[justusranvier]

The idea that the payment protocol doesn't support merge avoidance is bizarre, given that I coined the term merge avoidance in an article explaining how BIP 70 was already designed to support it, back in 2012. Being told that my own design doesn't support my own ideas - huh!

BIP 70 supports merge avoidance by allowing clients to submit multiple transactions to satisfy the requested set of outputs. This lets a client balance the outputs it has in its wallet with the outputs being requested by the payee, and the payee can try to ensure a decent distribution of outputs in its wallet by asking for them as appropriate.

BIP 70 does not require wallets to support generation of arbitrary numbers of outputs, because the client doesn't know what denominations the payee would need, and allowing the payee to specify the outputs precisely reduces the possibility for "dick moves" like a client paying the requested amount using an enormous number of tiny outputs, which would pointlessly force the recipient to pay extra fees when it isn't necessary. The payee is in the best position to know what kind of outputs it wants, not the payer.

It doesn't count if the payer has to ask permission from the payee. We'll only get privacy if it's the default behaviour, not optional behaviour which businesses can routinely deny. That's a great way to have a protocol that nominally supports something nobody can use in practise.

Businesses can deal with bad payment behaviour by customers in the same way they deal with difficult customers in general.