Network-level privacy of the various coinjoins from the coordinator's point of view, ordered from most vulnerable to least.
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)
Cyph3rp9nk
npub1ln…arrnt
2024-10-11 15:36:08
Author Public Key
npub1lnms53w04qt742qnhxag5d6awy7nz6055flnmjkr6jg39hm86dlq7arrntPublished at
2024-10-11 15:36:08Event JSON
{
"id": "81d14aebbe929b98e44a32bc239aa8be80053c1b5a6161962f49dc652dec241b",
"pubkey": "fcf70a45cfa817eaa813b9ba8a375d713d3169f4a27f3dcac3d49112df67d37e",
"created_at": 1728660968,
"kind": 1,
"tags": [],
"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"
}