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.

[Kruw]

You might want to read again that she's entering a round for the first time.

What is your point? I acknowledge she is entering a round for the first time and testing this round with her non-private UTXO and her private UTXO.

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.  

Why are you insisting that Alice can only have UTXOs that are known by chain analysis? Why can't Alice mine coins, use Lightning, or use Joinmarket to obtain a private UTXO?

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.

This means Alice and Charlie were in the same round, proving the coordinator is not Sybil attacking.

[BlackHatCoiner]

Why are you insisting that Alice can only have UTXOs that are known by chain analysis? Why can't Alice mine coins, use Lightning, or use Joinmarket to obtain a private UTXO?

So, let me get this clear: For Wasabi to offer privacy in a trustless manner, the user must have already gained privacy elsewhere. Therefore, there is no Sybil resistance for a user who only owns non-private coins.

This means Alice and Charlie were in the same round, proving the coordinator is not Sybil attacking.

I can't explain your line of reasoning. First, Charlie is de-anonymized. Then Alice is tricked into thinking that the coordinator is not malicious and joins the next round with coordinator's inputs, Charlie's already de-anonymized inputs and her inputs. That's a successful Sybil attack.

[Kruw]

So, let me get this clear: For Wasabi to offer privacy in a trustless manner, the user must have already gained privacy elsewhere.

No, the user also has the option of asking their friend to join a round or the option of PSBT monitoring like I described. There are 3 different methods you can use to ensure you are not being Sybil attacked.

I can't explain your line of reasoning. First, Charlie is de-anonymized. Then Alice is tricked into thinking that the coordinator is not malicious and joins the next round with coordinator's inputs, Charlie's already de-anonymized inputs and her inputs. That's a successful Sybil attack.

So Charlie and Alice coinjoin together and gain privacy together, defeating the coordinator's Sybil attack.

[BlackHatCoiner]

Nice. Trustless as long as me and my buddies come along. Maybe we should skip the extra step with the coordinator and construct the coinjoin ourselves.

Lol. Just lol.

[Kruw]

Trustless as long as me and my buddies come along.

No, it's always completely trustless no matter what, I told you that you already that you can 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. Since you didn't address it, I'm going to point out your blatantly wrong conclusion again:

Then Alice is tricked into thinking that the coordinator is not malicious and joins the next round with coordinator's inputs, Charlie's already de-anonymized inputs and her inputs. That's a successful Sybil attack.

The purpose of a Sybil attack is to PREVENT Alice and Charlie from participating in the same round. If Alice and Charlie just coinjoined together, that's a FAILED Sybil attack, not a SUCCESSFUL Sybil attack.

[Wind_FURY]

I was asking if sending the CoinJoined outputs to yourself through a multi-hop transaction in Lightning would add an extra layer of privacy. - I'm asking in case coordinators are sanctioned by the government.

Lightning adds an extra layer of privacy when you send to someone else too, so there's no point in "sending coinjoin outputs to yourself".

OK, that would help many people who hold UTXOs that are directly connected to sanctioned addresses gain on-chain fungibility back. I believe those UTXOs held by campaign managers of mixers that had their domains seized should open a channel and send themselves a multi-hop transaction through the Lightning Network. If any ex-members of those campaigns are reading this post, inform your fellow members and your campaign manager.

[BlackHatCoiner]

The purpose of a Sybil attack is to PREVENT Alice and Charlie from participating in the same round. If Alice and Charlie just coinjoined together, that's a FAILED Sybil attack, not a SUCCESSFUL Sybil attack.

If you read my message carefully, you'll notice that my point is this: since the coordinator knows Charlie's coins, he can block him as soon as Alice joins. If Alice quits the round again, to "test" that the coordinator isn't Sybil attacking, the coordinator can continue with what he did previously.

And all those points you're making are complete garbage. It's amusing that you're presenting them as exceptions, when in reality, the rule is that you don't need friends for a coinjoin, and the vast majority of people don't already have private coins before coinjoining. Let alone, export the PSBT and look on the inputs to see if they really register in the broadcasted coinjoin.

[Kruw]

Since the coordinator knows Charlie's coins, he can block him as soon as Alice joins.

This causes the attack to fail while also causing the attack to be detected by both Charlie and Alice.

And all those points you're making are complete garbage.

My points proved conclusively that coordinators are trustless. You can even use all 3 anti Sybil methods together at once, you don't have to rely on just one:

- First, register your private coin to the coordinator. If it's accepted, then there's no Sybil attack.
- Second, ask your friend to register a coin to the same round. If it's accepted, then you've confirmed for a second time that there's no Sybil attack.
- Third, just to be absolutely sure, back out of the round during signing to check to see if the transaction was built to target you. If the transaction is created, you've confirmed for a third time that there's no Sybil attack.

[graphite]

Sorry to interrupt the conversation but I had a questions about the wasabi coordinators protocol.

So from my understanding how it works is wasabi clients post UTXO's they want to coinjoin to the coordinator through tor. Then once the coordinator has a large enough set of UTXO's it will then request output addresses and amounts from each client. After that the cooridnator puts together the transaction and requests each client to sign their corresponding transaction.

Im sure Im missing something but my concern is with tor. Does tor use the same exit node when sending the input UTXO's and output addresses to the coordinator? If so wouldn't that mean the coordinator can deduce that the input UTXO's and output address coming from a specific exit node belong to the same wallet?