Post
Topic
Board Development & Technical Discussion
Re: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths!
by
Kruw
on 25/01/2024, 12:17:13 UTC
I somewhat agree. People will just assume you shill Wasabi.

Nope, these descriptions are agnostic of the wallet implementation.  There's multiple wallets that use each of the coinjoin methods I listed above, I'm not getting specific.

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts.

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with.  Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay.

Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

Clients abandon rounds after multiple successive failures as a basic way to prevent this.

_____________________________

I know you didn't mention it, but I disagree with this conclusion in section 7 of the WabiSabi paper:

Denial of service is not costless because unspent transaction outputs are a limited resource.

This is incomplete because the marginal cost of a DoS attack is zero if you are going to spend your UTXO anyways.

Look. I agree you believe you educate people about Bitcoin privacy, but we have repeated this conversation around solutions for privacy quite a lot of times. The fact that you still quote these whirlpool messages, as if they even mean something substantial, shows with what tenacity you're trying to sabotage Samourai.

What do you mean "as if they mean something substantial"?  These Whirlpool addresses are linked to each other.

There are no more mixer services here, stop trying to die on that hill. Or maybe you forgot to teleport your account to Altcoinstalks? Roll Eyes

I clicked on the link in your signature, it says "Jambler.io mixing platform".  Did you know this is custodial?

If there is a service coordinating payjoins between different wallets, which is ultimately what all of these methods boil down to, whose going to be interested in collecting the UTXO history of all the people who participate?

I believe the functionality your describing is "GroupHug" - https://peachbitcoin.com/blog/group-hug/index.html

However, as the article mentions, this does not provide privacy like WabiSabi and Whirlpool do.  gmaxwell explains the difference here:

Quote from: gmaxwell
Don't the users learn which inputs match up to which outputs?

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

Same with CoinJoins and coordinators. Let's say the Fed was running a coordinator, and recorded every UTXO going inside it. Where's the privacy now?

Takers in JoinMarket are the coordinator of their own coinjoin, so their threat is reversed (e.g. Feds running multiple maker identities to spy).

Privacy with WabiSabi is guaranteed by your client, it doesn't matter if the coordinator you connect to is a Fed or not because you do not reveal UTXO links to the coordinator or trust them with any data. 

If a Fed was running a Whirlpool coordinator, they could perform a targeted attack where they only choose you to mix in rounds with 4 decoys so you gain a false sense of privacy.  Or, they could just rug pull you by not mixing your funds after you pay the coordinator fee.