About coinjoin coordinators.
There is a difference to be made between privacy on-chain and privacy at the network level.
Even if you have chain privacy you can tag the addresses with their respective ips and trace the user. Obviously this can only be done by the coordinator.
This is why Samourai and Whirpool have always sucked.
Whirpool:
- If you used the mobile wallet without your node, the coinjoin was useless because your public keys were exposed to the backend and with them all your past, present and future addresses.
- If you used your own node or sparrow it was also of little use, since both samourai and sparrow reuse the tor circuit, they only generate a new one if you close the application, and therefore the coordinator can tag the incoming and outgoing addresses at the time of registration and ruin the coinjoin. Whirpool has never been zerolink, the coordinator knew everything.
Wabisabi:
- It creates new connections for both input and output addresses, so the coordinator sees distinct identities, although I think it has flaws in its design due to the delay. We can consider it to be zerolink, at least they tried and were honest.
Joinmarket:
- Since there is no centralized coordinator it is much less important to create new tor circuits for each connection, still the coordinator (the taker) will know the ips of the incoming and outgoing addresses. I don't know if they are mitigating this in any way.
Joinstr:
- Use Riseup VPN for logging, everyone uses the same VPN, there is no possibility of tagging inbound and outbound addresses across relays.
So... we're fucked either way? I thought using my own node with whirlpool would mitigate the problem. And when sw got shut down, I thought I was clever for using jam (joinmarket), lol.
What's the best alternative then? Using lightning, like submarine swaps?
Well, despite what Samourai's followers say, Wabisabi offers a good level of privacy, both at the chain and network level.
With Joinmarket you can achieve a good level of privacy as long as you alternate the roles of maker and taker.
With joinstr you get very good privacy.
All three methods are valid, with Lightning you get a good level of privacy as a sender.
With swaps you get a good level of privacy as well as long as you use tor.
I wouldn’t say that. Sure, any of the coinjoin coordinators could be compromised by specific parties, but chances are you’ll have better privacy than just leaving everything easy to trace by anyone.
Is it? If you do a bad coinjoin, then your utxo will stick out like a sore thumb in the ledger. Chainalysis might ask itself :"why would this person do a coinjoin?" A big anonymity set is crucial imo.
Joinstr uses Riseup VPN?
Yes, for everyone, anonymity by crowd, everyone has the same footprint.
It's a smart choice to not have to deal with tor circuit management.
You know I refused … respectfully
So the client has an always-on VPN to RiseUp, when they communicate with the relay? Or does it work differently?
(I should read up on it again. It's been a while..)
Exactly, the client creates a vpn connection to communicate with the relays.
We could say that the relays act as coordinators.
I wonder if it's not possible (and better) to use Keet/holepunch rooms powered by DHT as a more decentralized way for coordination, instead of Nostr relays.
I can't help but be wary that relay operator will be (forces to) censoring joinstr events , of pressured.
For the JM part, the taker will always know the maker linkages, independent of the network level isolation. There is no Chaumian blinding.
You are assuming that the Whirlpool coordinator kept records of the coinjoins and IPs and you have no proof of that
So it all comes down to trust in a third party, neither in cryptography nor in privacy can you trust a third party.
And more so when there are coinjoin implementations that have mitigated these problems.
There is no excuse, hence the stupidity of the samourai cult, something totally irrational by people who don't have the technical knowledge to understand these things.
The Whirlpool coordinator is blinded, it can't link input and outputs and TOR entities
😂 the coordinator can.
Stop repeat marketing, you were fooled.
Check the code.
Whirlpool uses a chaumian blinded coordinator. But I'm sure you've already checked the code.
You can learn something about the Whirlpool coordinator here
https://github.com/Samourai-Wallet/Whirlpool/blob/whirlpool/THEORY.md
I repeat again, they reuse the circuits, in the same documents it is said that it should not be done, in practice they do it. Again, check the code, check what tor does.
And the code honestly is crap and poorly structured.
Conservationists said what!
Here we can see how the Wabisabi client manages Tor identities during the coinjoin process.
DefaultCircuit: Circuit used for connections that do not require isolation, such as price queries or software updates.
SingleCircuitPerLifetime: Circuit created for inputs.
NewCircuitPerRequest: Independent circuits created for each output.
This is essential to have network privacy and not to be able to link inputs and outputs. Samourai or sparrow with whirpool would never have any kind of tor circuit management.
https://m.primal.net/LPHE.png
nostr:note12sl84488p7en2uzpyuzckdlpdag84tdke6g0g5ytn6gmprhf3guqxshjkx
Correct me if I am wrong, but wouldn't using something like rise up vpn, a third party operated service, give each third party all the data needed to correlate everything?
A vpn operator knows every source ip and their every destination and action and the promise of no logging is just that, a promise.
This is literally why people use Tor, and generate separate tor circuits per required identity.
PS, regarding wabisabi, circuits are constructed in advanced to prevent delays around tor circuit execution (although I think this is overkill), but also input, output registrations and anonymous credential reissuances has randomized delays built into it by design to prevent such correlation. Happy to answer more if you want to know more.
In joinstr the coordinator is the nostr relay, the vpn will only know that you are connecting to a relay.
The relay will not be able to correlate inbound and outbound because all clients will use the VPN IP addresses.
This is a simple option to avoid having to deal with tor circuits.
You are overestimating the effectiveness of a vpn here. The reality here is that we are focusing on very sophisticated difficult to execute attack vectors. The vpn is your only shield for all identities pushing to the relay here. Sure, https/wss encrypts the content, but an attacker that has compromised a vpn operator will listen to events on nostr relays that the vpn has connections to by its users, and can artificially delay data transfer to do timing analysis on events to correlate which ip sent which events with which pubkeys.
I am not the creator of joinstr, I am just saying why the creator has used the VPN option. The protocol is not even on mainnet and as far as I know, using tor circuits is an expected improvement.
I am aware that the right approach is wabisabi's. My post was mostly to emphasize whirpool's disastrous design in managing network connections.
https://gitlab.com/invincible-privacy/joinstr/-/blob/main/NIP.md?ref_type=heads
Oh sure, i just perceived that the initial post was insinuating "just use a vpn" was the best choice.
And no debate over the whirlpool one 😅
side note:
majority of devices do not have a public IP. So you're also hiding behind NAT.
I'm quite sure that my ISP is incompetent enough to fail to provide information leading to my MAC adress.
It's possible but I doubt it.
Cell phone connections are probably correlated to the imei of the sim card, and nat only hides internal devices but still gets an ip as a collective?
Oh, I meant desktops and home connections.
I'd hasitate to use phone for anything requiring privacy unless it's a pocket cash.
Imei (or a fingerprint) afaik are better way to identify you then ip. but with virtual providers and esims it's probably much harder for analitics.
still plausible
Post: Communication with the relay uses private channels.
Oddbean new post about login | logout 
