Bitcoin Forum

In another thread marcus of augustus says:


I'll break my rule about feeding trolls again to debunk for about the hundredth time the myth that the use of X.509 certificates in the payment protocol is bad for privacy.

It is not.

If you are in a customer/merchant situation, the customer's privacy is not affected AT ALL. The merchant's identity is in the X.509 certificate, the customer is as anonymous as always (which is very often "not anonymous", because the merchant needs to know something about the customer to deliver their product).

If you are a merchant, then part of the PURPOSE of the payment protocol is to provide a cryptographically secure, verified-in-some-way identity.

If you are a merchant and want an pseudanonymous then that is easy: set up an anonymous email address and then get a free email certificate from any of the certificate authorities that provide them.

If you have a philosophical hatred of X.509 and certificate authorities... then please invent a better identity verification system and get the world to adopt it. The payment protocol is specifically designed to make it easy to slide in a better system.

(but if you have a philosophical hatred of X.509 then what are you doing posting here at bitcointalk, whose security relies on the very X.509 certificates you find so despicable? There ARE alternatives, you should go hang out in forums.i2p or a Tor-based forum...)

That is only in case of tangible products. For digital products or online services merchant may not come to know the identity of the customer unless he/she deliberately discloses it.

http://www.crn.com/news/security/231600847/300-000-iranian-ip-addresses-compromised-in-diginotar-ssl-hack.htm

good luck with that on silk road

Tor has a couple of problems and isn't very different from a security perspective to the SSL hierarchy.

One is that people obtain Tor from a regular website, which is only guaranteed to be secure via SSL. So there's a bootstrapping problem.

Another problem is that on Tor, addresses are meaningless so it's easy to MITM people with phishing attacks. Silk Road tried to solve this by brute forcing an onion key with their name in it but phishing was still pretty common. Also the Tor developers are considering a new hidden service protocol that would make the onion addresses a lot longer, at which point brute forcing a prefix would not achieve much beyond requiring phishers to match the brute force because the suffix would be un-memorisable.

The problem of binding a human understandable and memorisable name to a public key is what certificate authorities are for. Tor doesn't solve that problem or even try: it just assumes you have a way to obtain the public key (onion address) for the website in a secure manner and punts on the whole issue of how that happens. Silk Road had a key hash that was short enough that you might be able to tell it to someone using your voice and have them remember it, or you could write it down, but that's certainly not any guarantee - Zooko's triangle posits that you can have an identifier that's secure, or memorable, but not both.

There's also some other more practical issues: one is that websites aren't going to migrate to Tor just to avoid certificate authorities, so the payment protocol has to work with the regular internet, which means X.509.

Another is that Tor is more centralised than the certificate authorities are: there are only seven directory authorities, and Tor is largely funded by the US government. There are about 100 independent CAs spread around the world and they're funded by their users.

(edited to remove erroneous statement)

What a bunch of crap.

First of all, had you invented a feature that people actually needed, the community would have embraced it without you advertising the shit all over.

Second, why would we want to "invent a better identity verification"?
Unlike you, there are people who don't like wasting time on developing useless features.
We've been doing really fine without your super payment protocol, just by using the old fashion GPG and its WoT.
And trust me: we are going to be still doing fine using these archaic tools.
The already implemented stealth addresses, combined with GPG's WoT, are far much better solution, then you shitty payment protocol based on central authorities run by corporations.
But how would you even know about an existence of such things, when you don't see anything behind the tip of your nose?

And last, but not least: it is bad for privacy!
You cannot get a certificate without providing your personal data to CA. And CA is a corporation that will always give this data out - if not for money than on a government's order. You cannot seriously pretend that you don't know it.
At the other hand, from the paying side, when I get to a merchant's web page that gives me SSL authenticated bitcoin deposit address and the amount I ought to send - why in a world would it not be enough for me?
Why would I need an additional, payment request, signed with exactly the same certificate?
Well, of course I don't need it, but you obviously very much care about us needing to use your payment requests... I just wonder why.

For me it is pretty obvious that you have developed this feature because some corporations delegated you to develop it.
And on this you spent like what, two years of development? And now you are disappointed because nobody wants to use it.

You wasted two years of time to develop this useless feature, while there were so much more important issues to address in the bitcoin software.
And here we are; few years later, the blocks are getting full and the only solution the bitcoin core lead dev has to address it, is still the same: we must increase the block size! Why we must increase the block size? Well, two reasons:
1) Because Gavin has not moved a finger to address any of the scalability issues. Decentralized off-chain transaction is apparently something that he was forbidden to purchase, since these solutions would make coin tracking much more complicated. Unlike the payment protocol..
2) Because he says, he doesn't care about mining. Well, keep not caring about mining, man - that will surely pay off for you :)

So to wrap up my post: well done, Gavin! As a bitcoin core developer, you can be really proud of yourself, for providing the community with features that one part doesn't care about, while the other part finds hostile to the actual bitcoin principles. And all at the cost of features that the community has been actually waiting for.

Please show some respect, X.509 certificates are good for sites like Coinbase, Bitpay, Bitstamp deposit or similars.
They are not meant for the average user, they are meant for the average bussines.

It is very useful to click a Bitpay payment link and dont have to double check the address (Bitcoin Core already shows a green background), It is very useful to have a receipt of every payment (verificable cryptographically) if something goes wrong, Its very useful to specify a return address (satoshidice problems with hosted wallets...).

If you dont like this features you can fork Bitcoin Core 0.7 and develop by yourself, I would like to download PiotrCore 0.9.1 to see its features.

Well, there is a partly alternative working system- Namecoin, although it can't deal with key distribution. If you're referring to X.509 you're actually referring to DNS. The DNS is controlled by the Internet corporation which defines who can issues certificates and domain names. So perhaps we can start with the acknowledgement of how the Internet actually works. X509 is an encoding standard. The Internet's root is controlled by a vast system of corporations and governments, and some opensource contributions (and very occasionally an Internet activist, see http://en.wikipedia.org/wiki/David_Chaum#cite_note-Cha81-20). How much do you users of the Internet (and Bitcoin) have to say about its inner workings? Is Bitcoin democratic/decentralized/anarchistic/...? And if so how does that relate to the development process? There is a mythology that Bitcoin follows the opensource model. Well, for example Linux ultimately depends on the discussion of one person (BDFL).

I think you're using the wrong terminology. What is a "payment" and what is a "merchant"? These concepts don't exist in Bitcoin. Bitcoin knows about keys, nodes and transactions. So you're imposing your own world view (literally) onto the system, without even the suggestion of an argument. The first thing would be to realize that Bitcoin is not just about cryptography and software, but economics, law, politics, etc. But you're basically stating apriori you don't want to deal with any of these complex problems. For example the whole notion of privacy is completely interlinked with law. Law of nation states operate on the principle that you can identify people (and indeed staying completely private is illegal in any country).

Exactly my point. This feature was developed for businesses, on their request, not for the bitcoin community on its request.


When I read that something is "very useful", the first question that comes to my mind is: how did you measure the very usefulness of it?
Obviously you didn't measure it - you are just giving us your subjective opinion.

As I said, had bitcoin users found these things "very useful" (and safe), they would have used them.
But they don't use the payment protocol and I seriously doubt that they ever will. Maybe a few, but definitely not most of us.

People are not stupid. You are not going to lure them into endangering their privacy by giving them a receipt of a payment.

Thank you for your permission. That's very generous.

In case you didn't notice, recently there has been major movement in alternative bitcoin solutions and alternative clients are already much further with new features, especially the ones that concern privacy. And mine is one of them, though it didn't have to come from any fork, I made it from scratch.

Considering that the Bitcoin Core goes against the current and the people's demand, it is rather inevitable that sooner or later it will only be used for mining.
Though only till the moment when miners finally realize that they have an alternative so they don't need to use software developed by a guy who proudly states in public that he doesn't care about mining.

I dont get it, how does X.509 give us issues with anonymity piotr_n?

You dont really define what the central authority is and what data that central authority retains due to X.509 being implemented in Bitcoin. At least make your case solid by explaining the problem in details instead of screaming out with a tin foil hat on your head.

CA's are "funded by their users"? How so? If you want to find out more about how CA's work I recommend this page: https://www.icann.org/resources/pages/certificate-authority-2012-02-25-en . Starting a discussion on that basis is difficult.

Tor is more "centralized" than CA's? 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

The TOR protocol was basically invented by David Chaum in 1981, http://en.wikipedia.org/wiki/Mix_network. It's the same guy who laid for the foundation for Bitcoin in the 80's. Clearly the idea of a mixing network is the exact opposite of attaching identities to nodes. In the link I posted above he argued recently that all routers could/should be TOR nodes. The whole point of mixing is to detach identity from actors. The whole point of CA's is the opposite.

piotr has a point. this was made not because it benefits p2p transfers or small business, but because developers are working for corporations.
you know if you're pushing tech like this, and then guiding development proposing to remove the block size limit .etc that's a dangerous thing. we can totally get rid of that and all the limits and have bitcoin owned by a cartel of corporations if you like... at least then transfers will be cheap but it will be the same as the banking cartel we have now.
but i get it, bitcoin for you is a nice fun way for consumers to make payments better between their centralised coporate silos legitimised through government legislation. bitcoin for americans.
what happens when the liberatory aspects of bitcoin come in conflict with the utility as a payments system? which will you favour at the expense of the other?
the features you work to promote, are the aspects of bitcoin that are grown, and don't forget the consensus.

mike, i don't even know what you're talking about. you are such a boot licker it's hilarious.

I said it, but if you insist, I can elaborate.

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.
Who is going to do this? Basically only corporations. Plus maybe a couple of crazy people..

Now, as a payer, you do not need a certificate, but then how does the payment protocol help you with anything?
Obviously you are not going to use it for sending money to your friends or buying stuff on black markets. You are also not going to use it for p2p bitcoin trading, nor for withdrawing your bitcoins from exchanges.
You may only be using it for sending your bitcoins to corporations (or the few crazy people). But each corporations already had a web page secured by SSL certificate - so why the hell to waste bitcoin development resources on them?
Better security? Give me a break! It does not make it anyhow more secure, to let a client extract a payment address from a binary file, rather than to let me just copy it from a web page, protected by the very same certificate.

Also, when you provide the refund address, this address identifies your wallet - another privacy concern.
And of course the recipient - a "very useful" thing, as someone has just said. The thing is that storing the receipts also keeps track of your past payments, which not everyone may be a fan of.
Not to mention that both; receipts and return addresses are already used in the bitcoin world, yet without the payment protocol.

In other words: they spent couple of years of development to reinvent the wheel.
A wheel which now needs a permission from a central certificate authority in order to work.
How crazy is that?


Moreover, let me remind you that very soon after 0.9.0 was released, there was a critical security issue reported in OpenSSL.
Basically a backdoor that could even cause your private keys to leak out from your wallet, through the "secured" payment protocol channel.
It was fixed - yes, but do you really believe that this is going to be the last critical security issue ever discovered in OpenSSL? Well, if you do, then you must be a very naive person and have no much experience with software development. Everyone who is so stubborn to build secured applications around the messy openssl lib is IMHO insane.

BTW, I remember someone once assured me that the bitcoin client would not connect to any server when doing the payment protocol things. No matter what, it wasn't supposed to connect anywhere!
But then it makes me wonder: how is it possible that a payment protocol was vulnerable to the heartbleed bug, if it wasn't connecting anywhere?
Obviously someone had lied to me - obviously there are some connections, just not quite official.
So why did that someone lie to us?
Well, either because he is incompetent and he has no clue what kind of software he develops, or because he is just a liar.
Either way - a wrong person to develop a software for my needs.

This is the crux of the issue - the payment protocol is bad for privacy because of what it doesn't do.

One of the biggest problems for Bitcoin privacy is that the way we use it now does not allow for merge avoidance strategies. A good (privacy-respecting) payment protocol would not deliver to the client a fixed list of outputs - it would deliver information that would allow the client to construct as many outputs as it desired.

That also ties in with the plague of address reuse, which is still an unsolved problem since the standardization on deterministic wallets hasn't happened yet.

Good luck taking your screenshot of the "SSL authenticated bitcoin deposit address and the amount" to court when the merchant claims you didn't pay.

In other words, you don't really understand which problems the payment protocol is trying to solve.

Which court? If the merchant is in Chile and the customer in Russia, what use is this? Bitcoin is a global system, but there is no world court people can go to, to settle disputes. This can in theory only apply if the two parties agree which court settles disputes, and the court even considers itself responsible. If you're drafting social protocols you should have some understanding of how economic transactions work. Commercial transactions consist of much more than just the payment itself (what happens if there is no delivery, delivery not on time, bad deliveries, ...). And if you want to integrate with legal systems via software, you better clearly specify what you're talking about. Since when is the Bitcoin network dependent on courts?! And if the payment protocol addresses any of these issues, why is it not stated in the draft protocol. That's what these kinds of documents are there for. You would find that it would be much like writing law, because you would have to first define merchants, customers, payments. And then Bitcoin is not about "payments" between merchants and customers. It's about transactions between peers. So the nature of the system and the debate already has shifted dramatically.

Who said anything about screenshots?

I meant something like the receipts localbitcoins issues. Or whatever message "pay this amount, to this address, for this product", signed with a private key - that's all you need for a digital receipt, mr big smartass but small imagination.

And BTW, good luck taking your payment protocol receipt to court when the merchant claims you didn't pay.
You are obviously living in a dream world. Though most Americans do, so you are just following the pattern. :)

It will work for the same jurisdiction, but not cross-jurisdiction. It could even be such that a merchant has to automatically acknowledge if a payment was received via the public blockchain. One example implementation would be forcing the merchant to use a certain address which is attached to the name (the merchant wouldn't be able to generate arbitrary addresses). In effect that's what the DAC/smart contract ideas are about. Registering a corporation is equivalent to assinging a payment address to a legal entity. A limited liability company is in a sense nothing else than a restricted account. Some of this can be implemented today, but I very much doubt that Bitcoin is going to be the system doing this (i.e. anything interesting in the future).

Well, if I didn't know a few people who were told by their lawyers that digital receipts (issued by localbitcoins) would not be accepted as an evidence in court, then I would have also thought like this.

The problem is that our justice system is still in a previous century. They don't know what a digital signature is and they are more likely to accept a piece of paper that came from a printer, rather than a digitally signed file.

I am not saying that no court would ever accept a digitally signed receipt, but I am saying that they are very reluctant to do so.

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?

The vast majority of internet transactions are "local" to one judicial system, and also follow a standard template (I pay you X, you send me Y).  A signed statement of X and Y, along with blockchain evidence that X was completed, gives the purchaser some confidence that they will have some useful recourse in the event that the vendor fails to complete Y.


And how is PGP or bitcoin signing any better?  Do you ask the court for a subpoena to search all of their records for evidence that they possess the private key that signed your receipt?  Or do you think that the judge will take your word for it that you've brought suit against the correct party?

One nice thing about being an American is knowing that our courts do, for the most part, understand cryptography and digital signatures.

Not too bright.

It is better, because I don't need to send a stool sample to a corporation, in order to receive the signing key.



So what the court would do differently, with your digital receipt?
It would go just the same way; whoever signed it can simply testify that someone hacked his server, stole the key and therefore it wasn't him who signed this data.
Or better: the key leaked out through the heartbleed issue. Go ahead and prove that it didn't...

And at that moment the case is closed - you cannot use such a receipt even to wipe up your own ass.



Right... that must be the kind of signatures you use under the death sentences, when executing people all over the world. Shortly before the missile hits a peasant, or his kid, there is a quick and efficient algo, built into the system, that digitally signs the sentence, so they'd get executed in compliance with your very democratic constitution end extremely solid justice system. :)

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.


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).

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.


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.

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?

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.



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.

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?

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?

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

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.

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.

He's got a point there.

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

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

@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 :)

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.

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.

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.

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.

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.

Payments with merge avoidance are more expensive for the payee to redeem so you do have to ask permission.

Note BTW that the intent of merge avoidance - as described in Mike Hearn's original writeup - was to be an alternative to CoinJoin that still had some privacy while also allowing blacklists to be applied. Merge flexibility w/ CoinJoin is a much better idea and fights against blacklisting. Similarly cut-thru payments, which the payment protocol can support.

I've never heard a good explanation for how CoinJoin could possibly work for realtime payments, since it's only secure if all the outputs in the join are exactly the same size. Trying to use it this way sounds like a setup for security theatre.

Accepting credit/debit cards is more expensive for the payee, so they deal with it by incorporating the cost into their prices.

I've never heard a good explanation for how CoinJoin could possibly work for realtime payments, since it's only secure if all the outputs in the join are exactly the same size. Trying to use it this way sounds like a setup for security theatre.

Not sure why that is. Legally speaking, which is almost 100% what we care about(or maybe it's just me?), even careless joins make taint harder.

Careless joins are trivial to reverse, and all that means is taint applications will upgrade their algorithms.

Just because blockchain.info doesn't yet display how easy it is to reverse a join doesn't mean they actually accomplish anything from a privacy or liability perspective.

This is getting offtopic, but you cannot distinguish a "careless join" from one with different correspondence  which transferred value. E.g. A provides 1 btc, B provides 2 BTC,  C takes 2 BTC, D takes 1 BTC. Is it a trivial B->C A->D or is B paying A and the roles reversed or is it a single party transaction with change and some odd coin selection?  If you'd like to discuss this further, take it to the CoinJoin thread— better to discuss this there than half of what has been there recently. :)

This is actually relevant to both threads.

The odds of being a single party transaction are low, since it's rare for a user to have an input exactly matching the desired output size for typical spends, so that possibility could probably be ignored in a system that was trying to perform mass surveillance.

The "B paying A and the roles reversed" case also seems low-probability unless clients which implement CoinJoin routinely perform this operation. For example, if instead of creating change normally the payer's client always asked the payee to send them the change amount from their own address as part of the Payment Protocol. B wants to pay A 1 BTC, but the only single output large enough is 2 BTC. So B asks A to return the excess 1 BTC as part of the same transaction.

Even assuming the Payment Protocol supports the payer asking the payee to construct the transaction this way, there's still a double coincidence of wants that would seem to make that a rare case as well (A needs to have an unspent output that's exactly the right size for this to work).

Sorry for the dumb question but what do you call "careless joins" ?

No it doesn't, as change can still be taken. For all combinations of inputs and outputs there is some party/party payment matrix that allows any output party to be any input party, though indeed, some are more plausible than others.

WRT payment protocol, indeed, you'd want the receiver to also be able to specify additional inputs you'd like them to include, which is also good for consolidating the receivers wallet— sort of the opposite of merge avoidance, but privacy superior because it results in confusing merges... but the payment protocol is extensible, so it just requires someone who cares to specify that out and get it implemented.

This:

A careless join is one in which the correct solution is obviously the most plausible. Note that evaluating different solutions to the matrix lends itself well to parallel processing, there is no time limit since everything is permanently recorded in the blockchain, and mass surveillance doesn't require 100% accuracy.

Probably the only way to make CoinJoin useful in real-world situations is to build into the clients the exact same type of analysis tools attackers will use to reverse the joins so that clients can evaluate any proposed join prior to agreeing to it. (That's a good subject for the other thread).

Sender and receiver both need to be able to specify inputs and outputs, and the receiver should be flexible regarding the amounts of the outputs. Instead of saying "Create an output of value X", the receiver should specify "The net value transferred to me (my outputs - my inputs) must equal X".

Thanks ! I get it. BTW, I've posted a comment in coinjoin thread (to avoid pollution of this thread).