Myth: the Payment Protocol is bad for privacy

[Peter Todd]

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.

[1713530112]

1713530112

[1713530112]

1713530112

[1713530112]

1713530112

[1713530112]

1713530112

[justusranvier]

Merge flexibility w/ CoinJoin is a much better idea and fights against blacklisting.

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.

[justusranvier]

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

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

Merge flexibility w/ CoinJoin is a much better idea and fights against blacklisting.

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.

[instagibbs]

Merge flexibility w/ CoinJoin is a much better idea and fights against blacklisting.

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.

[justusranvier]

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.

[gmaxwell]

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

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.

[justusranvier]

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

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

[laurentmt]

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

[gmaxwell]

(A needs to have an unspent output that's exactly the right size for this to work).

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.

[justusranvier]

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

This:

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.

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

you'd want the receiver to also be able to specify additional inputs you'd like them to include

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

[laurentmt]

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

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