Pages:
Author

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

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.
legendary
Activity: 2898
Merit: 1823
What's your opinion on adding an extra layer of privacy after a CoinJoin through sending your CoinJoined outputs to yourself through the Lightning Network?

You don't even need to send them to yourself on Lightning, you can just spend anywhere on Lightning privately.


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.

What if a coordinator is a honeypot, and they could monitor the outputs that went through them.

Every single Bitcoin node can monitor outputs that went through a coordinator's coinjoins since Bitcoin is a public blockchain, so there's no "honeypot" involved with the coordinator's node.


?

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?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
A Sybil attack becomes much easier to execute if the coordinator is malicious. They could simply accept a small number of coins for the round and replace the rest with coins controlled by chain analysis. This would undermine the reliability of the anonymity set.

And this becomes exponentially more effective when there sits little liquidity in the coordinator. This is why I have claimed in the past that the protocol is not entirely trustless.

You can detect if a coordinator is attempting a Sybil attack. I explained this to you already, remember?

Could you explain how the Sybil attack will be detected?

Yes:  You try to register a private coin in the same round as your non private coin that is the supposed target of the attack.  If your private coin isn't denied, then the round is not under a Sybil attack.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
A Sybil attack becomes much easier to execute if the coordinator is malicious. They could simply accept a small number of coins for the round and replace the rest with coins controlled by chain analysis. This would undermine the reliability of the anonymity set.

And this becomes exponentially more effective when there sits little liquidity in the coordinator. This is why I have claimed in the past that the protocol is not entirely trustless.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
This is like making your software insecure and fragile, on purpose.

You're lying. zkSNACKs did absolutely nothing to degrade the security or durability of Wasabi's software.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Why? So that their service could operate smoothly. It seemed like a reasonable deal: making a minimal gesture to the authorities in exchange for a greater "public good."
Picture this: You're a company that aims to improve Bitcoin privacy. To me, this means combating surveillance resulting from blockchain analysis. The enemy, among every blockchain spectator out there, is primarily blockchain surveillance firms, as they hold vast amounts of data, ranging from the light wallet servers they operate to the numerous data points they buy and sell with third parties, such as KYC data, IP addresses, etc.

What would you think of this company's integrity if it suddenly announced that it would be funding the enemy? That's essentially what happened, as far as the public is aware. Of course, they didn't say, "we will be funding blockchain surveillance", but something like "we will buy information about the inputs". But in reality, they were only making these firms more powerful by buying into this harmful notion. Here's another strange and suspicious aspect of this situation: why purchase from these firms when you openly acknowledge that their analysis is based on false positives?

And even we justify all that; justify zkSNACKs for preemptively starting funding blockchain analysis and blacklisting, and blame it on the authorities for potentially pressuring them in the future. How on Earth can one justify that their input registration was permitted by the blockchain analysis firm? This is like making your software insecure and fragile, on purpose. People with the greatest incentive to break coinjoins suddenly had the power over who is allowed to join a coinjoin. This is nuts.

If you're asking me, this is way too much gesture to the authorities, and ultimately for no reason. zkSNACKs had similar confrontation by the US government, as Samourai did, despite the fact that they (zk) sold out their users.

And these were just two of the practices employed by Wasabi; there are countless other red flags that make it impossible for me to trust them with my privacy, even if the client software is open-source.

Those participating in the signature campaigns couldn’t have known that one day all mixer services, even the oldest ChipMixer, would shut down.
We knew. No centralized service can survive over the long term; that's the reason Bitcoin was created.

We certainly weren't "scamming" anyone, as there was often a warning that using the X mixer required you to trust it with your coins. Calling this practice a scam is as baseless as claiming that those who directed you to FTX were scamming, simply because they might have foreseen its shutdown, given the numerous examples of other CEXs that had been hacked or gone bankrupt.

Why is there this pettiness? You, the "old-timers" here, labeled Kruw a scammer for months, accusing him of collaborating with the government.
To clarify my position: I don't believe Kruw is a scammer (and if I ever referred to him as such, I publicly apologize). Whether or not constantly evading arguments is considered fraudulent is open to debate. But, I have actually defended him against people who labeled him a scammer due to this recent bug. I do, however, find him untrustworthy for the reasons I've outlined in here.

Why can't we draw a line and look to the future?
Well, we have to. Without privacy solutions like coinjoins, Bitcoin becomes the wet dream of blockchain surveillance. It's just that the solutions currently available, in my view, are insufficient. At least comparably to privacy technologies employed by Monero. (It's been a while since I paid with Bitcoin last time.)

Perhaps the line we need to draw is against maximalism, where anything that cannot be implemented in the Bitcoin protocol is dismissed as "unnecessary shitcoin features".
legendary
Activity: 2534
Merit: 1713
Top Crypto Casino
Whether he is dishonest (or can be considered dishonest, is) open for debate but the type of characteristics he has consistently displayed over a long period of time certainly have shown him to be someone that will not be liked or appreciated by the majority in this forum. Regarding the actual number of funds that were coin joined through his co-ordinator, it seems Open Coordinator will probably catch up fast.

Over $1 billion worth of total coinjoin volume has been calculated so far by Wasabist's explorer!
I find it really peculiar how this much Money has been Coin Joined through the Coordinator functioned by one of the most dishonest persons I saw around here.
newbie
Activity: 5
Merit: 8
Thank you very much for your answers, especially for the tips regarding Trezor and Lightning.

- "Wasabicoordinator[.]io"s gains from triggering this fee bypass were limited to ~triple the regular rate users would have normally paid for coinjoining with zkSNACKs, allowing them to "siphon" the funds of participants who think they are only paying the 0.003% fee rate the coordinator advertised.

If I understand correctly, the "siphoning" didn’t mean that the rogue coordinator was "sweeping" coins or accessing private keys. This, along with the updates that have taken place since then, is reassuring.

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.

Some people doesn't find the delicate balance reasonable, especially because zkSNACKs used to mention blockchain analysis company as part of mass surveillance[2]. And FWIW, you also had to edit configuration file to switch coordinator. I expect only few of Wasabi wallet user aware of it.

Yes, that's true, but they quickly adapted to the changes in the market. The new version immediately allowed for more user-friendly handling of coordinators. In the latest version, you can even set a coordinator fee cap, and it includes default protection settings. Overall, I see these as positive developments. Blockchain analysis and mass surveillance were definitely not the right direction. I completely share the concerns about these issues. Thankfully, they are now a thing of the past (or so it seems).
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
Hey folks, I've been observing what's going on here for months. Now I've reached the point where I want to speak up. What I see, as an outsider:

Hi, welcome to the forum.

Wasabi Wallet has become more open and transparent than ever before, driven by necessity! Am I wrong? The coordinator fee has been abolished, and anyone can become a coordinator. "Let a hundred flowers bloom." The mixers have fallen in the struggle. Every reputable mixer. Sparrow has removed Whirlpool. Trezor has discontinued CoinJoin based on the Wasabi coordinator.

I think you wanted to say "The coordinator has been abolished" instead (without word "fee"), since that's what zkSNACKs did[1].

What has happened in recent years? Wasabi tried to find some delicate balance between the authorities and privacy. Why? So that their service could operate smoothly. It seemed like a reasonable deal: making a minimal gesture to the authorities in exchange for a greater "public good." Excluding marked coins from CoinJoin never meant they were blocked. You could still mix them with another coordinator. It just wasn't advertised. Wasabi obviously wanted to profit. That lasted until now. The unfortunate case with Samourai has shown that this is not possible!

Some people doesn't find the delicate balance reasonable, especially because zkSNACKs used to mention blockchain analysis company as part of mass surveillance[2]. And FWIW, you also had to edit configuration file to switch coordinator. I expect only few of Wasabi wallet user aware of it.

Due to the full-court press by authorities against mixers, we are in a new era. Currently, with Wasabi and a freely chosen (free) coordinator, it’s the ONLY way for an average user who wants to use CoinJoin to ensure privacy. Everyone else is out of the game. Or am I wrong? Suggest alternatives if I’m missing something. (I know about XMR, but right now I’m talking about BTC.)

Ginger Wallet[3] and joinstr[4] may fit your criteria.

[1] https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/
[2] https://web.archive.org/web/20181228073613/https://wasabiwallet.io/
[3] https://gingerwallet.io/
[4] https://joinstr.xyz/
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
What's your opinion on adding an extra layer of privacy after a CoinJoin through sending your CoinJoined outputs to yourself through the Lightning Network?

You don't even need to send them to yourself on Lightning, you can just spend anywhere on Lightning privately.

What if a coordinator is a honeypot, and they could monitor the outputs that went through them.

Every single Bitcoin node can monitor outputs that went through a coordinator's coinjoins since Bitcoin is a public blockchain, so there's no "honeypot" involved with the coordinator's node.
legendary
Activity: 2898
Merit: 1823
Over $1 billion worth of total coinjoin volume has been calculated so far by Wasabist's explorer!




What's your opinion on adding an extra layer of privacy after a CoinJoin through sending your CoinJoined outputs to yourself through the Lightning Network?

What if a coordinator is a honeypot, and they could monitor the outputs that went through them. Would they be capable of monitoring those outputs if they passed through a multi-hop transaction in the Lightning Network?
Pages:
Jump to: