Topic: Myth: the Payment Protocol is bad for privacy (Read 4623 times)

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

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

@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

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