Scammer lead developer resigns from honeypot Wasabi Wallet

[LoyceV]

zkSNACKs already successfully convinced their remaining user base that the current collaboration with blockchain analysis is not a privacy issue, so I think they'll market it successfully, again.

One thing still isn't clear to me: does the coinjoin coordinator see which input belongs to which output? If so, they know everything. If not, I'm curious how it works on a technical level (but don't really want to spend time on it since I'll never use them anyway).

[1714243651]

1714243651

[DaveF]

Wouldn't it be more likely for all privacy minded users to abandon Wasabi entirely? Even if the current bad reputation isn't enough, that will end the moment it's bought by a blockchain analysis company.

The "privacy minded users" are not their target. Instead their target is the majority who don't really understand how to improve their privacy and are too lazy to do any research so they end up in a honeypot like Wasabi wallet.....

I posted it earlier someplace but we are not their target audience for the most part. It's businesses that want 'privacy theater' so you can have peoples coins and put on a nice show that due to the fact that they are using this wallet with this feature that people can have privacy. And look we will never send you 'tainted' coins because these nice people are checking them for you.

Much like people buying bitcoin ETFs instead of just buying coin.

...Tor ...

Tor is pointless, no you can't steal funds with this attack using Tor but to think it provides privacy is weak at best.

https://therecord.media/thousands-of-tor-exit-nodes-attacked-cryptocurrency-users-over-the-past-year


-Dave

[LoyceV]

Tor is pointless, no you can't steal funds with this attack using Tor but to think it provides privacy is weak at best.

https://therecord.media/thousands-of-tor-exit-nodes-attacked-cryptocurrency-users-over-the-past-year

Isn't it the other way around: SSL stripping doesn't reduce your privacy, but it makes you send Bitcoin to the wrong address.

[DaveF]

Tor is pointless, no you can't steal funds with this attack using Tor but to think it provides privacy is weak at best.

https://therecord.media/thousands-of-tor-exit-nodes-attacked-cryptocurrency-users-over-the-past-year

Isn't it the other way around: SSL stripping doesn't reduce your privacy, but it makes you send Bitcoin to the wrong address.

The point I was making is that if you are either a motivated criminal or a business or a government spinning up a ton of exit nodes and other services is not difficult.
And it makes people using 'many different exit nodes' for privacy loose a lot of it.

The tor cannot be tracked is bogus considering the number of tor sites that have been traced / seized over the years.

-Dave

[kayirigi]

Wasabi team members pump lots of fake volume in to Wasabi. Probably funded by BC analysis. Support their failing wallet and make fake volume. Makes self sybilling very easy and unmixing Wasabi coinjoins very easy. Wasabi team members have admitted this. Evidence in my first post!

[Dont Trust Verify]

zkSNACKs already successfully convinced their remaining user base that the current collaboration with blockchain analysis is not a privacy issue, so I think they'll market it successfully, again.

One thing still isn't clear to me: does the coinjoin coordinator see which input belongs to which output? If so, they know everything. If not, I'm curious how it works on a technical level (but don't really want to spend time on it since I'll never use them anyway).

Nobody in this thread seems to know anything about how it works yet they make all these nonsense claims.

No, they cannot see which input belongs to which output. https://docs.wasabiwallet.io/using-wasabi/CoinJoin.html#wabisabi-protocol-step-by-step

[kayirigi]

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

[LoyceV]

No, they cannot see which input belongs to which output. https://docs.wasabiwallet.io/using-wasabi/CoinJoin.html#wabisabi-protocol-step-by-step

Thanks for this link. So they did actually think it through. But this sounds easy enough to do:

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

That's going to be expensive on transaction fees, but sounds plausible.

[DaveF]

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

And beyond that from here:
https://docs.wasabiwallet.io/using-wasabi/CoinJoin.html#wabisabi-protocol-step-by-step

It is very important that the coordinator cannot link Alice to Bob. Because Alice has sent the cleartext input, and Bob sends the cleartext output. So, if the two were to be linked, then the coordinator can specifically link the input to the output, meaning that the anonymity set is 1. Because Alice received a credential from the coordinator, and because Bob is a new Tor identity not linked to Alice, the coordinator can verify that nobody is cheating, but it cannot deanonymize the peers.

because of this:
https://www.makeuseof.com/tor-exit-nodes-spying/
and this:
https://www.reddit.com/r/TOR/comments/mkd1s5/79_of_all_tor_nodes_are_hosted_within_14_eyes/
and this:
https://nusenu.medium.com/tracking-one-year-of-malicious-tor-exit-relay-activities-part-ii-85c80875c5df

Thinking that sending in cleartext is a good idea or that it provides any anonymity is a joke a best.

-Dave

[BlackHatCoiner]

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

Even if they do not sybil attack themselves, their back-end unit tests reveal that they request input approval from a chain analysis company (probably Coinfirm). A company which have a great incentive, I'll say, to execute a sybil attack.

I don't want to engage in Wasabi discussions since I think we've covered that arc and there isn't anything more to say, but even if Wasabi is not a honeypot and we ignore all the evidence of Wasabi being flawed software, it's just naive to put trust on people with principles that do not align with Bitcoin's.

[...]

I think you've misread something. First things first, the links you've mentioned talk about the exit nodes (which are your "way out" to the clearnet). Wasabi utilizes hidden services, that means, no exit nodes intervene.

[DaveF]

I think you've misread something. First things first, the links you've mentioned talk about the exit nodes (which are your "way out" to the clearnet). Wasabi utilizes hidden services, that means, no exit nodes intervene.

Yes, I grabbed the wrong links I'm mobile / remote at the moment.

But you are still passing information to hidden services in clear text. The links I wanted to grab discussed that sending things in the clear was now creating a need to trust the person getting the data (in this case wasabi but they were discussing ahem...other things) and the person running the last hop that service was connecting to which 99% of the time was the service itself.

Might not be making myself 100% clear here but the best way to say it is that since the wasabi coordinator itself is getting the info in cleartext unless they are running their onion services on the same server then somewhere even if it's just between Virtual Machine 1 and Virtual Machine 2 on the same physical hardware blade there is still data being unencrypted data being passed. Is it a 'real' threat? Depends on how they are doing things.

In the end, probably not important since you are trusting them to do things they way they say they are doing them anyway.

-Dave

[kayirigi]

That's going to be expensive on transaction fees, but sounds plausible.

Very cheap actually. Or even free. Coordinator fee for self sybilling inputs goes back to them so this costs nothing. Coordinator fee from the target can cover sybil inputs transaction fee. Target pays for the sybilling, Wasabi pays nothing.

Or government says to BC analysis buddies 'we pay you to track this input' and so Wasabi can make a profit by self sybilling.

[mikeywith]

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

Just to keep fair criticism here, sybil attacks in coinjoins are easily detectable, in order for the attack to work efficiently in deanonymizing a certain input -- the coordinator needs to refuse connection confirmations from all other participants, so if your input has not been spent before and the coordinator rejects your connection it's safe to assume that it's preparing for a Sybil attack on an input it identified earlier in the current round.

Obviously, at this stage, it's hard to tell if enough adequate users still use Wasabi to spot sybil attacks.

[DaveF]

They self sybil and fill Wasabi with fake volume. Very easy for them to link inputs and outputs.

Just to keep fair criticism here, sybil attacks in coinjoins are easily detectable, in order for the attack to work efficiently in deanonymizing a certain input -- the coordinator needs to refuse connection confirmations from all other participants, so if your input has not been spent before and the coordinator rejects your connection it's safe to assume that it's preparing for a Sybil attack on an input it identified earlier in the current round.

Obviously, at this stage, it's hard to tell if enough adequate users still use Wasabi to spot sybil attacks.

In *theory* couldn't all their transactions be sybil attacks. All inputs except 1 for each mix come from them / known source. Every time the coodinator sees something coming in it has local wallets fill the rest of the space so to speak.

Yes there is a large cost and complexity. But we are talking millions of dollars at most, not an unobtainable amount of money for a business.

-Dave

[mikeywith]

In *theory* couldn't all their transactions be sybil attacks. All inputs except 1 for each mix come from them / known source. Every time the coodinator sees something coming in it has local wallets fill the rest of the space so to speak.

That would also be detectable, the minimum number of participants is 100 in a single round, and the timeout IIRC is 60 mins, unless the max figure is reached, I can't recall all the details but to make a long story short; the number of coinjoin rounds are guessable, a scenario like the one you described would make the number of successful rounds exponentially large.

Furthermore, you could use two identities at the same time and see if they end up in the same round or a different one, it would be pretty obvious for anyone observing wasabi to spot such an attack.

Besides, depending on your anonymity set target (they changed the name and the math behind the score but logic still applies) the coordinator would need to prepare all kinds of different input sizes to attack everyone, it is not feasible.

One way they might attack you is by signing the blinded outputs using a different private key, of which then they can brute force the number of unblinded outputs to figure out which input belongs to what output, I am not sure how Wasabi/GovSnacks prevents such attacks.

[BlackHatCoiner]

Just to keep fair criticism here, sybil attacks in coinjoins are easily detectable

They are easily detectable if the developers have dedicated a part of their software on defending the user from such attacks. Bitcoin Core has worked on it, for example. The user cannot be expected to use all sort of coins, from different devices, for the sake of confirming they aren't under sybil attack. I haven't found anything substantial in their client's repository.

But you are still passing information to hidden services in clear text.

I still don't get it, though. What does it matter? Alice and Bob are two separate Tor identities. Their messages are different.

[mikeywith]

They are easily detectable if the developers have dedicated a part of their software on defending the user from such attacks. Bitcoin Core has worked on it, for example. The user cannot be expected to use all sort of coins, from different devices, for the sake of confirming they aren't under sybil attack. I haven't found anything substantial in their client's repository.

I feel like we are talking about different things, sybil attacks in Coinjoins are pretty useless if you are not the coordinator, if you want to attack me you need to guess the exact round that i would be joining + stop others from joining the same round or in other words make every other participant (you) which I can't think how would it be possible.

If you are indeed the coordinator then you have got an edge, you could simply reject all other users in the round I am joining and the attack will work, but again, doing that would be obvious because other users who have valid inputs will be rejected for no good reason and that would indicate the coordinator is attempting the attack.

Sybil attacks on the p2p network are different, since other nodes won't care if your node is rejecting them or has gone offline, since there is no central coordinator the whole thing is different.  

[n0nce]

If you are indeed the coordinator then you have got an edge, you could simply reject all other users in the round I am joining and the attack will work, but again, doing that would be obvious because other users who have valid inputs will be rejected for no good reason and that would indicate the coordinator is attempting the attack.

Couldn't the coordinator just use own inputs and 'prioritize' them over real user inputs whenever they need to do a sybil attack? How would that be obvious to other users? It could easily be that those are not coordinator inputs but that it's real user demand that's simply higher than usual for a brief period of time, no?

I don't think users get something like a timestamped proof that they submitted inputs to a CoinJoin at a certain point in time (could be used to show that they entered the CoinJoin before the coordinator started to attack), right?

[mikeywith]

Couldn't the coordinator just use own inputs and 'prioritize' them over real user inputs whenever they need to do a sybil attack? How would that be obvious to other users? It could easily be that those are not coordinator inputs but that it's real user demand that's simply higher than usual for a brief period of time, no?

if the number of inputs exceeds the maximum number set by the coordinator which I think is 400 for their new protocol, the coordinator would automatically arrange another round.

But then we really need to reach some ground on defining the purpose of sybil attacks, be it those done by outside attackers or the coordinator itself, the point of sybil attacks in a coinjoin is to bring the anonymity set for the victim to 1, it's the only possible way to link x input to y output -- otherwise, the attack would only reduce the anonymity set/score.

The coordinator could certainly force you into a conjoin that has 399 inputs it owns and 1 is yours, but that means, there will be a coinjoin for every "real" participant, while that is doable in theory, it would certainly raise the flag (you can register 2 different inputs and see if they end up in different rounds every time you do that).


Also, round status is publically available through Wasabi API, you can acquire the current input count, if the current round is at the input registering phase and has 50 registered inputs, and then you try to register 2 different valid inputs and they end up in a different round, you know they are doing something fishy.

Obviously, if they have a targeted input (or a few of them) to which they want to link -- then that would make sense, and they could be doing that already and manage to hide it but a full-scale Sybil attack is just not feasible IMO.

I don't think users get something like a timestamped proof that they submitted inputs to a CoinJoin at a certain point in time (could be used to show that they entered the CoinJoin before the coordinator started to attack), right?

timestamped proof? not sure,  A proof, yes, the coordinator creates Tor identity at input registration, obviously the person who receives it knows the time at which they received the credential, I don't think they can prove it to someone else.

With that said, I am not claiming Wasabi don't/won't do any of that, I am just stating that it would be very difficult to hide a sybil attack, besides, Wasabi doesn't need any more criticism, you make chain analysis scums richer every time you use it.

[BlackHatCoiner]

If you are indeed the coordinator then you have got an edge, you could simply reject all other users in the round I am joining and the attack will work, but again, doing that would be obvious because other users who have valid inputs will be rejected for no good reason and that would indicate the coordinator is attempting the attack.

And what's a "valid" input? Is there such a terminology in their repository? The coordinator can start rejecting certain inputs as "naughty" (which is part of their terminology btw), and the users are required to accept this with no questioning. Their blacklisting does not indicate sybil attack attempt, as far as they've put it.

Quoting myself from the past:

You register 10 (non-private) inputs, and 1 of them gets rejected, what is your conclusion? To me, absolutely none. Coinfirm might have deemed this one input as inappropriate, or it might be trying to get rid of some coinjoin inputs, so they can use theirs instead and de-anonymize the remaining registered inputs. Who knows. For instance, a 150-input long coinjoin can have its 75 inputs rejected, and replaced with 75 Coinfirm inputs. That leaves the firm with 50% less output set to account for.

Sybil attacks on the p2p network are different, since other nodes won't care if your node is rejecting them or has gone offline, since there is no central coordinator the whole thing is different. 

I agree that it is more effective and less costly to execute in coinjoin. The victim of a sybil attack in Bitcoin Core is the client which connects with malicious nodes exclusively, which possess significant computational power. The victim of a sybil attack in Wasabi coinjoin is to connect with just one malicious entity.