Wasabi Wallet - Total Privacy For Bitcoin

[BlackHatCoiner]

If a coin is private, how could Chainanalysis refuse it?

Not sure how I am supposed to answer this question. By doing it? Seeing that the private coin isn't in their possession nor in their list of de-anonymized coins, and therefore blocking it from joining? We've seen numerous examples of people depositing coins in CEX and getting them refused due to blockchain analysis deeming them illicit. Coins coming out of mixers, coinjoins, etc. Why couldn't that happen when the blockchain analysis firm decides which coins the coordinator accepts?

What message did your client say when you tested a Sybil attack against it with your coordinator? I'm wondering how you came to that conclusion.

I came to that conclusion, because I searched the source code and I found no warnings that have to do with Sybil attack. In fact, the word "sybil" does not exist in the client: https://github.com/search?q=repo%3AWalletWasabi%2FWalletWasabi+sybil&type=code. Can you direct me to the part of the client's code that warns the user about coordinator attacks?

[Kruw]

Not sure how I am supposed to answer this question. By doing it?

When they do it, that makes the Sybil attack detectable.

I came to that conclusion, because I searched the source code and I found no warnings that have to do with Sybil attack. In fact, the word "sybil" does not exist in the client: https://github.com/search?q=repo%3AWalletWasabi%2FWalletWasabi+sybil&type=code. Can you direct me to the part of the client's code that warns the user about coordinator attacks?

So you didn't even test the supposed vulnerability in the client before making a false accusation? Wow. It's just like your other false accusation when you said WabiSabi has a worse Boltzmann score than Whirlpool despite never actually calculating any scores. Here's screenshots of the multiple warnings in the client that you said "absolutely" aren't there:

Bold message in the coinjoin status box -



Yellow /!\ symbol in the coin list -

[BlackHatCoiner]

It's just like your other false accusation when you said WabiSabi has a worse Boltzmann score than Whirlpool despite never actually calculating any scores.

I did not calculate any scores, because due to the size of WabiSabi coinjoin, the program would never finish. However, coinjoins with variable amounts will have less Boltzmann score. (This score can be calculated if the malicious coordinator can use their inputs to weaken the anonymity set, since the real inputs and outputs which are being mixed become much less.)

Here's screenshots of the multiple warnings in the client that you said "absolutely" aren't there

Strawman. I never said it does not display your coins being rejected. I said it does not warn for a Sybil attack. Just because some of your funds are rejected, or just because you can't participate in a coinjoin, does not tell whether the coordinator is Sybil attacking you, or whether the chain analysis firm simply disapproves your coins.

[Kruw]

I did not calculate any scores, because due to the size of WabiSabi coinjoin, the program would never finish. However, coinjoins with variable amounts will have less Boltzmann score.

Let's compare these two coinjoins:

6 outputs for 0.5 BTC: https://mempool.space/tx/b3f111610fca28d34d8132c82e7901bf79ecd7e5979060568fe81fad3d18aec6

6 outputs for 0.5 BTC + 195 other outputs with variable amounts: https://mempool.space/tx/24e7f4c6fbdabd8cd8499fbfd407894c4a590cf5d355937436d08dd8e8c5ecb3

Explain why the presence of the 195 other outputs makes the second coinjoin less private than the first one.

Strawman. I never said it does not display your coins being rejected. I said it does not warn for a Sybil attack. Just because some of your funds are rejected, or just because you can't participate in a coinjoin, does not tell whether the coordinator is Sybil attacking you, or whether the chain analysis firm simply disapproves your coins.

It's not a strawman, if you are still unsatisfied with the client's detection system, why don't you simply ask your friend to join the same coinjoin round as you to verify there's no Sybil attack taking place?

[BlackHatCoiner]

Explain why the presence of the 195 other outputs makes the second coinjoin less private than the first one.

It can be better understood if you compared a shorter coinjoin, which instead of 228 inputs, it'd have 6 (as in whirlpool), since we're talking about the case where most of these hundreds of inputs are disguised as anonymity set, but are maliciously added by the coordinator (which is theirs).

So, a 6 input, 6 output coinjoin with variable amounts would look like this:

Code:

0.50 BTC    0.50 BTC   
0.40 BTC    0.40 BTC
0.30 BTC -> 0.30 BTC
0.20 BTC    0.20 BTC
0.10 BTC    0.10 BTC
0.05 BTC    0.05 BTC

Is there any probability that the input of 0.10 BTC can have created the 0.50 BTC output? No. The only ways to create the 0.50 TXO would be if one of the following conditions was true:

Code:

User owns: 0.50 TXI
User owns: 0.40 and 0.30 TXI
User owns: 0.40 and 0.20 TXI
User owns: 0.40 and 0.10 TXI
User owns: 0.30 and 0.20 TXI

Therefore, if we know beforehand that Alice controls only the 0.10 TXI, we could ignore certain outputs (in this case all the other outputs). The only explanation would be that Alice controls the 0.10 TXO, because it is impossible that she could have created another output. Now, this, incidentally influences other people's privacy, as now it is evident that Bob (with his 0.50 TXI) cannot have created the 0.40 and 0.10 TXO.

Let's have a look on the whirlpool coinjoin: (rounding down to 0.50 BTC for each TXI),

Code:

0.50 BTC    0.50 BTC   
0.50 BTC    0.50 BTC
0.50 BTC -> 0.50 BTC
0.50 BTC    0.50 BTC
0.50 BTC    0.50 BTC
0.50 BTC    0.50 BTC

What are the probabilities that each of the inputs created the TXO_0? All equal, 16.6%. Even if you employ blockchain analysis, and know with high degree of certainty that Alice controls only one of the inputs, the result is still the same. You could only know that Alice's TXO cannot be x, because x was consolidated with y (and we know that Alice does not control two inputs). To mitigate this issue, you only allow from your users to select only one of their UTXO to join the round. (Still does not completely protect against a malicious coordinator, but makes it more expensive, and complicated as consolidations from more rounds need to be taken into consideration and users can choose to remix indefinitely.)

It's not a strawman, if you are still unsatisfied with the client's detection system, why don't you simply ask your friend to join the same coinjoin round as you to verify there's no Sybil attack taking place?

I join, my coins pass the coordinator's approval, my friend's coins are refused. Why is this considered Sybil attack and it's not my friend's coins "naughty" according to blockchain analysis?

[Kruw]

So, a 6 input, 6 output coinjoin with variable amounts would look like this:

Code:

0.50 BTC    0.50 BTC   
0.40 BTC    0.40 BTC
0.30 BTC -> 0.30 BTC
0.20 BTC    0.20 BTC
0.10 BTC    0.10 BTC
0.05 BTC    0.05 BTC

It would look nothing like this, refer to the actual mainnet coinjoin I posted. This is how the variable amount denominations work: https://github.com/WalletWasabi/WalletWasabi/pull/13326

since we're talking about the case where most of these hundreds of inputs are disguised as anonymity set, but are maliciously added by the coordinator (which is theirs).

No, we're not talking about this case since Boltzmann score has absolutely nothing to do with Sybil attacks.

Therefore, if we know beforehand that Alice controls only the 0.10 TXI, we could ignore certain outputs (in this case all the other outputs).

But you don't know that information  

I join, my coins pass the coordinator's approval, my friend's coins are refused. Why is this considered Sybil attack and it's not my friend's coins "naughty" according to blockchain analysis?

Ta da! By asking your friend to register their coins, you've revealed the coordinator is trying to Sybil attack you   Now you can drain the Sybil attacker's entire wallet.

[BlackHatCoiner]

It would look nothing like this, refer to the actual mainnet coinjoin I posted. This is how the variable amount denominations work: https://github.com/WalletWasabi/WalletWasabi/pull/13326

Same logic applies with these denominations.

No, we're not talking about this case since Boltzmann score has absolutely nothing to do with Sybil attacks.

Boltzmann score is useful in case of a malicious coordinator weakening the anonymity set, to the point where only a minority of the inputs and outputs are not registered by the coordinator.

But you don't know that information

You do have this information if you partner with blockchain analysis.

Ta da! By asking your friend to register their coins, you've revealed the coordinator is trying to Sybil attack you

This sentence makes no sense, but even if I need a friend for protection, the anonymity set remains weak, and the protocol is not trustless. I still have to rely on others whom I trust to join coins with me.

[Kruw]

Boltzmann score is useful in case of a malicious coordinator weakening the anonymity set, to the point where only a minority of the inputs and outputs are not registered by the coordinator.

Then that would mean Whirlpool has zero "Boltzmann score" since the coordinator is trusted to choose every participant for the round.

You do have this information if you partner with blockchain analysis.

No you don't, Alice could have any combination of coins. "partnering with blockchain analysis" doesn't penetrate the anonymity of her open source client.

but even if I need a friend for protection

You don't need a friend, as I mentioned before, you can singlehandedly test for a Sybil attack by registering 2 inputs yourself.

[BlackHatCoiner]

Then that would mean Whirlpool has zero "Boltzmann score" since the coordinator is trusted to choose every participant for the round.

If the coordinator is malicious and launches Sybil attacks, ordinary blockchain observers will see a positive Boltzmann score. For any coinjoin participant, the score will be better approximated (it will be lower, because they can deduct their inputs/outputs). In the event of a successful Sybil attack where every coin in a coinjoin is compromised (with, for example, n coins, of which n-1 belong to the attacker), the Boltzmann score becomes meaningless for the coordinator. The score is designed to approximate scenarios with uncertainty, whereas in this case, there is none.

No you don't, Alice could have any combination of coins. "partnering with blockchain analysis" doesn't penetrate the anonymity of her open source client.

Before joining her first round, Alice is expected to only have non-private coins, and if these coins are de-anonymized by the chain analysis company, then her "open source client" provides her with no anonymity.

You don't need a friend, as I mentioned before, you can singlehandedly test for a Sybil attack by registering 2 inputs yourself.

By registering 2 inputs which are tagged from blockchain analysis as belonging to the same person, it tests absolutely nothing. The coordinator can still attack, since they know with certainty that these 2 inputs belong to the same person.

[Kruw]

Before joining her first round, Alice is expected to only have non-private coins

This expectation is what allows Alice to detect the Sybil attack because her other private UTXO will be rejected.

By registering 2 inputs which are tagged from blockchain analysis as belonging to the same person, it tests absolutely nothing. The coordinator can still attack, since they know with certainty that these 2 inputs belong to the same person.

Knowing that 2 inputs belong to the same person still doesn't allow the attack to go undetected because that person could have a third input.

Now you can drain the Sybil attacker's entire wallet.

You didn't acknowledge earlier when I said earlier "now you can drain the Sybil attacker's entire wallet"- there's a third way to detect a coordinator Sybil attacking EVEN if you have only one UTXO, EVEN if you don't have any friends who will participate, EVEN if this UTXO is known as belonging to the target by chain analysis, AND will force the attacker to bleed fees:

- Register your input
- Go to signing to receive the PSBT listing all of the inputs in the round
- Force quit the round and monitor these inputs from the initial round to make sure they are spent in the next blame round

The attacker then has to pay the mining fee for an entire coinjoin since all of his dummy UTXOs were exposed to their target while the target pays nothing at all.

[BlackHatCoiner]

This expectation is what allows Alice to detect the Sybil attack because her other private UTXO will be rejected.

You might want to read again that she's entering a round for the first time. (Or you might want to ignore it and act like I never said it, which is what you're very successfully at doing since 2022.)

Knowing that 2 inputs belong to the same person still doesn't allow the attack to go undetected because that person could have a third input.

The number of inputs make no difference. The fact is that if chain analysis company has de-anonymized Alice's coins and knows with certainty where all of her coins sit, which is trivial for the vast majority of people buying from KYC-ed exchanges, then no matter how many inputs she uses to coinjoin, the coordinator can attack her. Only if she uses a private coin, she can suspect of this attack (and yet, no certainty of her being attacked or her coins being deemed as "naughty" by the client).

Now it's time for you to argue that she should be running her own coordinator and join coins with herself before she enters another one. That would be the icing to the cake.  

The attacker then has to pay the mining fee for an entire coinjoin since all of his dummy UTXOs were exposed to their target while the target pays nothing at all.

Now it only takes Charlie, whose coins are also de-anonymized by blockchain analysis, and who will not engage in all this manual mumbo-jumbo. And after successfully attacking that user, it'd also give the impression to Alice that the coordinator is not malicious.