Bitcoin Forum
October 03, 2022, 05:26:19 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Myth: the Payment Protocol is bad for privacy  (Read 4490 times)
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1113


View Profile
June 03, 2014, 11:23:25 AM
 #41

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.

1664774779
Hero Member
*
Offline Offline

Posts: 1664774779

View Profile Personal Message (Offline)

Ignore
1664774779
Reply with quote  #2

1664774779
Report to moderator
1664774779
Hero Member
*
Offline Offline

Posts: 1664774779

View Profile Personal Message (Offline)

Ignore
1664774779
Reply with quote  #2

1664774779
Report to moderator
The block chain is the main innovation of Bitcoin. It is the first distributed timestamping system.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1664774779
Hero Member
*
Offline Offline

Posts: 1664774779

View Profile Personal Message (Offline)

Ignore
1664774779
Reply with quote  #2

1664774779
Report to moderator
1664774779
Hero Member
*
Offline Offline

Posts: 1664774779

View Profile Personal Message (Offline)

Ignore
1664774779
Reply with quote  #2

1664774779
Report to moderator
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 03, 2014, 12:53:50 PM
 #42

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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 03, 2014, 12:58:54 PM
 #43

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
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
June 03, 2014, 02:28:42 PM
 #44

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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 03, 2014, 02:40:47 PM
 #45

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
Moderator
Legendary
*
expert
Offline Offline

Activity: 3752
Merit: 6875



View Profile
June 03, 2014, 03:59:55 PM
 #46

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. Smiley
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 03, 2014, 04:35:47 PM
 #47

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. Smiley
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
Sr. Member
****
Offline Offline

Activity: 384
Merit: 255


View Profile
June 03, 2014, 04:41:35 PM
 #48

Sorry for the dumb question but what do you call "careless joins" ?
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3752
Merit: 6875



View Profile
June 03, 2014, 04:50:33 PM
 #49

(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
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 03, 2014, 06:41:22 PM
 #50

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
Sr. Member
****
Offline Offline

Activity: 384
Merit: 255


View Profile
June 03, 2014, 09:13:55 PM
 #51

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).
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!