5 ms·

Why 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

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

trhtrsh 14y ago
An outgoing payment need not be human-present. It can be automated on a randomized schedule. The same argument could be made against cash's anonymity.
- mootothemax 14y ago
  An outgoing payment need not be human-present. It can be automated on a randomized schedule. You can split it into a million micropayments whilst you're at it; it still doesn't stop the information leak. The same argument could be made against cash's anonymity. Can you explain this in a bit more detail? I'm not sure I understand.
  - MacsHeadroom 14y ago
    >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? Not a chance.
    - deleted 14y ago
      [deleted]
    - mootothemax 14y ago
      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. You're kidding yourself if you believe otherwise.
SilasX 14y ago
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.
- mootothemax 14y ago
  I really disagree with you regarding complexity. Think about how Google's search engine works. That's a seriously complicated piece of kit, storing vast amounts of data. Do you really think analysing millions or billions of rows of incredibly database-friendly records is that tricky by comparison?
  - SilasX 14y ago
    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.
Gormo 14y ago
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.

trhtrsh 14y ago

An outgoing payment need not be human-present. It can be automated on a randomized schedule. The same argument could be made against cash's anonymity.

mootothemax 14y ago
An outgoing payment need not be human-present. It can be automated on a randomized schedule. You can split it into a million micropayments whilst you're at it; it still doesn't stop the information leak. The same argument could be made against cash's anonymity. Can you explain this in a bit more detail? I'm not sure I understand.
- MacsHeadroom 14y ago
  >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? Not a chance.
  - deleted 14y ago
    [deleted]
  - mootothemax 14y ago
    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. You're kidding yourself if you believe otherwise.

SilasX 14y ago

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.

mootothemax 14y ago
I really disagree with you regarding complexity. Think about how Google's search engine works. That's a seriously complicated piece of kit, storing vast amounts of data. Do you really think analysing millions or billions of rows of incredibly database-friendly records is that tricky by comparison?
- SilasX 14y ago
  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.

Gormo 14y ago

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.