Pages:
Author

Topic: Wasabi Wallet - Open Source, Noncustodial Coinjoin Software - page 14. (Read 11391 times)

legendary
Activity: 2898
Merit: 1823
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. Cool
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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  Huh

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  Grin Now you can drain the Sybil attacker's entire wallet.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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 -

legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
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".

Confused by that. Here's a hypothetical question. Is there no way for a malicious operator, assuming it is more than 80% of the total liquidity, to monitor and follow the outputs that CoinJoined through its coordinator? How? Why?

No, adding more liquidity is not sufficient to break the privacy of a coinjoin. The attacker would also have to block honest liquidity from participating (which would be detected).

If your private coins were refused, it would mean absolutely nothing. You couldn't know if it's a Sybil attack or chain analysis refusing to accept private coins

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

What you "explained" in that discussion, is that you already need to have private coins for the process to be trustless, which besides ridiculous, is also false, as the client software makes absolutely no Sybil warnings to the user in case their private coins are refused.

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.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
I think you wanted to say "The coordinator has been abolished" instead (without word "fee"), since that's what zkSNACKs did[1].
Yes and no. You're right that the coordinator itself has been abolished, but so has the fee, as the whole concept has shifted towards a more free and open model. Take, for example, Wabisator - Wabisabi Coordinators List, including Kruw's free coordinator.

IMO Wasabi wallet become more free and open (where you can easily use different coordinator) because otherwise their wallet wouldn't have much unique feature. As for fee, it depends on which CJ coordinator you use.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
You can detect if a coordinator is attempting a Sybil attack. I explained this to you already, remember?
  • If your private coins were refused, it would mean absolutely nothing. You couldn't know if it's a Sybil attack or chain analysis refusing to accept private coins, and zkSNACKs wouldn't tell you why they got refused.
  • What you "explained" in that discussion, is that you already need to have private coins for the process to be trustless, which besides ridiculous, is also false, as the client software makes absolutely no Sybil warnings to the user in case their private coins are refused.
Pages:
Jump to: