Here, I am done - I think this makes sense.
Read this while reviewing the flow chaeplin posted:
The transactions sent from the mixer (C) to the end address is of a set size (his example was 10). This is D.
He can then search the blockchain for possible candidates (value 10) via a script. Which gets us to block 28531 - this matches the 10.00 XC value. This can be linked at blocked 28533 with the mixer C - we already know C (output 9.99999).
This allows him to trace back to 28531 in the blockchain - to find the values that == 10.00 and match to a specific address - in this case: XQdBjeQtH1JGrkd2MWcXbtsRVeKHWZbnqa which is B.
You can then take all the transactions for this address B - review them and find two matching amounts that == 10 which belong to one single address. This address is A. Since this address B has never been used before this transaction - this is easy to do - and - even if it had multiple transactions - they would not all related back to one single point with one single value (10).
Thanks, this seems a clear explanation.
To prevent this kind of tracking, the solution could be multiple node used for one transaction. Is this the multipath revision announced by the dev? What is DRK solution to prevent this kind of analysis?