A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties. So the Payment Protocol should be CoinJoin. |
|
|
|
well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market I'm sure there's plenty of money available to fund that. The question is whether or not you can get funding to produce the tools that let the general public protect themselves from it. |
|
|
|
Moreover, till now, main heuristics used for analysis of the transaction graph are "quite simple" (tainting, "address reuse" and "change address" patterns) and I guess it's just the first generation (at least which is publicized). I'm quite sure that more elaborated tools (temporal patterns, behavorial patterns) combined with side-channels attacks (data gathered from peripheral systems like exchanges, merchants, ...) could provide stunning results. The problem is that those tools are all being developed behind closed doors, which gives the attackers an advantage. Too many people think a low taint score displayed on blockchain.info provides them with meaningful protection. I'll predict though that for all this investment money flowing into Bitcoin startups, not one VC is going to fund investment into open source graph analysis tools that could help individuals measure their privacy and warn them before they do something that will compromise it. |
|
|
|
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". |
|
|
|
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). |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
That's a little harsh considering the context of etotheipi's comment. You might be right. I'm a bit on edge by the number of high profile developers who seem to be herding Bitcoin toward a dystopian surveillance nightmare, or at least not actively working to prevent it. Maybe we can take this context as as example of exactly why financial privacy should be a higher priority. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
Nobody wants to talk about making life easier for graph analysis, apparently.
|
|
|
|
In the words of Gavin, "Time to feed the trolls". Gavin has a dangerous and irresponsible attitude toward properly responding to criticism, and it doesn't help my confidence in your software to see you adopting it. |
|
|
|
You could probably pre-deposit a certain amount of btc into an Uber account if they had that option. Then the needed amount would be withdrawn.
This is exactly what I was going to suggest, but why would you be ok trusting a company with your credit or bank details but not Bitcoin? There's nothing to stop them draining your account at the moment is there? Search for "Bitcoin micropayment channels" |
|
|
|
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. 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. |
|
|
|
|
I like your threads, but you really should put them in the correct forum section.
|
|
|
|
Ah, this is more like the good old days Nothing like a flash crash to get the blood pumping. The cool part about the Bitcoin growth cycle is that no matter how many times it happens, each time there's a new group of people who've never seen it before. |
|
|
|
Economists on the other hand works for institutions that are largely government-funded, and that means that money flows in regardless of the quality of their work (and that's an understatement). It's not a matter of quality as it is a matter of not understanding the actual job of economists. The job of economist is to produce convincing ex post facto justifications for government policies. This is what they get paid for, and that's what they do. The public's incorrect assumption that their job has anything to do with objective truth makes their job easier, so it's not a mistake they are interested in correcting. |
|
|
|
Why do you ask? I haven't asked any questions. marcus_of_augustus asked one, and Kristov Atlas asked another. |
|
|
|
|
Yes, timestamps can be forged.
If someone was careful enough and had plenty of fakes nodes, they could fabricate such a thing.
|
|
|
|
|
Show Posts
