Btw, I got an idea just now: It would be an interesting twist if one could send to two addresses instead of one, in a single transaction, with the sent amount being broken into two randomly sized parts. For example I send you 16 DRK and you get 5.4 DRK in one address and 10.6 DRK in another. You still got 16 but it's in two addresses so noone can corelate my 16 output and your receiving of ..5.4 and 10.6. If a further layer is added (for practical purposes) to treat these addresses as one (for the sender and receiver) it could also be quite easy to use. Kind of meta-addresses that overlap/include the sending/receiving addresses.
ok -- but with a timing analysis, the number of transactions in (let's say) a 60 second window will be relatively few, so it's not too hard to reconstruct what really happened, especially with uncommon amounts (e.g. I send you 16.023957).
[Note- i don't know what is chain pooling that you mentioned...]
When someone here ran a script to calculate the rich-list (many pages back), I remember he/she managed to correlate between different addresses as being part of the same wallet.
So if I understand correct, what AlexGR suggested sounds intriguing, but 'hackable'.
My question is- what if we take it further and instead of having the transactions divided between several addresses, it ius divided into several 'wallets' that reside on the same qt, feed from the same blackchain dat, but each having a separate wallet.dat file/keys ?
As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them.
Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point.
So lets say 3 people each put in 100 coins
A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F
The outputs will be
2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I
Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.
A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.
The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.
Evan can you clarify?
Hell, come on, crypto? Most of us are geeks if not aspies, LOL. Hell, even the "attacks" are probably from another aspie, LOL.
