{"created_at":1728660968,"pubkey":"fcf70a45cfa817eaa813b9ba8a375d713d3169f4a27f3dcac3d49112df67d37e","content":"Network-level privacy of the various coinjoins from the coordinator's point of view, ordered from most vulnerable to least.\n\nWhirpool (regardless of whether you use tor or not, it's useless):\n\nA (192.168.1.1) - D (192.168.1.1)\nB (192.168.1.2) - C (192.168.1.2)\nC (192.168.1.3) - B (192.168.1.3)\nD (192.168.1.4) - A (192.168.1.4)\n\nWabisabi (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):\n\nA (192.168.1.1) - D (192.168.1.4)\nB (192.168.1.2) - C (192.168.1.5)\nC (192.168.1.3) - B (192.168.1.6)\nD (192.168.1.1) - A (192.168.1.7)\n\nJoinstr(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):\n\nA (192.168.1.1) - D (192.168.1.1)\nB (192.168.1.1) - C (192.168.1.1)\nC (192.168.1.1) - B (192.168.1.1)\nD (192.168.1.1) - A (192.168.1.1)\n\nJoinmarket, 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).\n\nA (192.168.1.1) - D (192.168.1.1)\nB (192.168.1.2) - C (192.168.1.2)\nC (192.168.1.3) - B (192.168.1.3)\nD (192.168.1.4) - A (192.168.1.4)\n","sig":"f8e80f05670299e1f577daadc9483ac42907a64b3488bb0193f687b9bfad38b6269a277ceb2dc862a0baae01ffdc32b203e3674706bf7d5e913c6e63cd6a1860","id":"81d14aebbe929b98e44a32bc239aa8be80053c1b5a6161962f49dc652dec241b","kind":1,"tags":[]}