And it's one of the worst structured code I've ever seen and people trusted these guys with their privacy....
https://github.com/Archive-Samourai-Wallet/whirlpool-client/commit/fbee9e820f511661c888a53c75a5e5e610b000f5
quotingNetwork-level privacy of the various coinjoins from the coordinator's point of view, ordered from most vulnerable to least.
note1s8g…97w9
Whirpool (regardless of whether you use tor or not, it's useless):
A (192.168.1.1) - D (192.168.1.1)
B (192.168.1.2) - C (192.168.1.2)
C (192.168.1.3) - B (192.168.1.3)
D (192.168.1.4) - A (192.168.1.4)
Wabisabi (let's assume that a user has two entries. I put the second one because it is a centralized service, but it really has a good implementation):
A (192.168.1.1) - D (192.168.1.4)
B (192.168.1.2) - C (192.168.1.5)
C (192.168.1.3) - B (192.168.1.6)
D (192.168.1.1) - A (192.168.1.7)
Joinstr(The VPN is a centralized point but the coordinator is a relay, and the relay will only see the same ip, although you could associate the two, vpn and relay, if a 3-letter agency intervenes, you can mitigate by changing relay between rounds):
A (192.168.1.1) - D (192.168.1.1)
B (192.168.1.1) - C (192.168.1.1)
C (192.168.1.1) - B (192.168.1.1)
D (192.168.1.1) - A (192.168.1.1)
Joinmarket, the coordinator is the taker, this mitigates the collection of the information, therefore it is not vulnerable to a network level tagging attack (from my point of view).
A (192.168.1.1) - D (192.168.1.1)
B (192.168.1.2) - C (192.168.1.2)
C (192.168.1.3) - B (192.168.1.3)
D (192.168.1.4) - A (192.168.1.4)