Because what you've just described is still just obfuscation.
With this method, incoming and outgoing payments would be asynchronous, so it would be hard to use timestamps to associate them.
Doesn't matter. An outgoing payment will happen at some point in your day, and unless you have zero time patterns in your life, it will help identify you. As will the resulting services and people you send money to, even if the pieces start as small and as basic as "Orders pizza."
I don't see how that would work unless you already had a priori identifying information for the person who performed the transaction.
If I deposit 500 BTC every Friday, and immediately transfer it into the mixing account, then order a pizza for 10 BTC on a Tuesday, paid for from via mixing account, how would you confirm that I was the one who ordered the pizza? All you can determine for certain is that (a) I am a subscriber to the mixing account, and (b) someone who subscribes to the mixing account ordered a pizza. If there are a million subscribers to the mixing account, without access to their internal records, there's no way to conclusively associate outgoing payments with specific subscribers.
>You can split it into a million micropayments whilst you're at it; it still doesn't stop the information leak.
Yes it does. If I split one payment into three different sizes and send them hours apart while I'm sleeping, from a shared eWallet used daily by 1000 other people, you think that is going to be traceable to me in any way?
You want to buy a pizza for yourself or someone else. At some point your transactions will have been gathered together to do so, either in the merchant's wallet or elsewhere.
Hey presto, there's some information. Either about liking to buy pizza, having friends in country X, or being based in country X.
Trace it backwards, you have a list of people potentially involved.
I'm not saying that a single transaction will identify you. However, much like that EFF browser identity page, it doesn't take many bits of information - plus a few "likely good with computers" type guesses - to start putting together a list of very plausible identities.
That might be feasible if you had ten people using it with 100 addresses (where you know one of the public keys of each of them). The problem difficulty almost certainly scales up too quickly to work with a thousand people and a million addresses.
Well, I don't think you're really qualified to disagree, considering that you're revealing ignorance of the relevant domain (computational complexity theory) by arbitrarily equating different problems as "complex but still solvable".
Well, some problems are so hard (in the rigorous complexity-theoretic sense) that no amount of hardware is going to make a difference. For example, problems currently classed as NP-hard take, in the general case, an amount of time that increases exponentially in the problem size, so past a certain threshold, take too much time even given all the computers on earth.
The problem you'd have to solve here is basically the subset sum problem: given a set of transfers in an out of a mixer (let's say you already know which addresses it uses, which is not easy since it can make new ones for free) which subsets of the transfers out have the same totals as which subsets of transfers coming in? (From that point you identify one in/out set of addresses as belonging to the same person.)
That problem likewise takes exponential time to solve in the general case. And since the mixer chooses the transfers, they can pick it so that it's hard to find solution partitions (i.e. drive it to the part of the problem space where heuristics help the least).
Or they could go the opposite approach and add a random, time varying tolerance (i.e. charge a fee that varies between x and y % over time, or promise that you might get up to x% more or y% less than you put in) that makes the problems extremely underdetermined so that there are arbitrarily many constraint-satisfying solutions thus that the aggregate data is uninformative.
No, "Google solves complex problems" does not prove what you think it does.
> The problem you'd have to solve here is basically the subset sum problem: given a set of transfers in an out of a mixer (let's say you already know which addresses it uses, which is not easy since it can make new ones for free) which subsets of the transfers out have the same totals as which subsets of transfers coming in?
This isn't even the right problem, given the usage model that I posited and to which mootothemax replied; if you keep a balance stored in the mixing account, to which you make deposits on a regular payments, then it's highly unlikely that outgoing payments will match incoming payments in the first place. How often do you currently deposit checks into your bank account in exactly the same amount as outgoing payments that you immediately write after making the deposit?
There'd be no conclusively correlating information here; payments into the mixing account would have different amounts and timestamps from payments going out of it, and in order to use inferences taken from patterns as identifying information - e.g. someone orders a pizza from Mario's Pizzeria every Tuesday at 7 PM - you'd have to already have identifying information about the person you're trying to find in the first place, e.g. that I live near Mario's and happen to enjoy their pizza.
It's not just that the complexity of the problem increases with scale, it's that the reliability of the correlations you can make also decreases with scale.
I think it's a bit rich to accuse me of not being qualified to disagree when you've decided to ignore the other half of the equation: that the transfers ultimately end up elsewhere, ie the merchant's wallet.
I fear that as long as you and I fling accusations like this at one another, no good will come of this thread, so propose we end it thus: I consider the problem solveable; and you do not.
Because what you've just described is still just obfuscation.
With this method, incoming and outgoing payments would be asynchronous, so it would be hard to use timestamps to associate them.
Doesn't matter. An outgoing payment will happen at some point in your day, and unless you have zero time patterns in your life, it will help identify you. As will the resulting services and people you send money to, even if the pieces start as small and as basic as "Orders pizza."