Pages:
Author

Topic: Scammer lead developer resigns from honeypot Wasabi Wallet (Read 1375 times)

jr. member
Activity: 34
Merit: 33
besides, whatever you suggested could be applied to all other Coinjoins that use a centralized coordinator, which is why I said "let's keep criticism" fair.


If Wasabi sybil you your coordinator fee pays for their transaction fees and so sybil is free for them.
If Samourai sybil you you pay nothing after 1 round and they pay transaction fee for every round so sybil is very expensive for them.

Not the same at all. And Wasabi devs ADMITTED to self sybilling!
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
Still, however, the worst coinjoin is probably better than the best centralized exchange when privacy is at stake.
Equally bad, in my opinion. Privacy enhancing services are reputation-based. If you have a bad reputation, I won't trust you. Judging by the (not so recent anymore) events in Wasabi, I would put it in the same rack with centralized exchanges. Honestly, even if the former is a mixing service, I cannot trust it my privacy in the slightest; if used, I'd consider it invaded, just as with centralized exchanges.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
If you want to hide your transactions from friends and you're willing to go through a centralized company anyway, it's cheaper to use an regular exchange.

You can but there is a huge difference, centralized exchanges are custodial and KYCed whereby coinjoins are not, besides most coinjoin services are somewhat centralized anyway given that they use a centralized coordinator, which is why joinmarket is a superior option since they use orderbook over internet relay chat without a centralized coordinator.

Still, however, the worst coinjoin is probably better than the best centralized exchange when privacy is at stake.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
Think about it this way: someone who wants to coinjoin to maintain a good level of privacy against friends, co-workers, customers paying them in BTC, or any other reason where the privacy you know isn't the center of it. To that someone, using Wasabi is probably a better option. They could think that since this service goes through a government filter, what comes out of it is going to be "clean" coins, making them safe for future cash-out.
If you want to hide your transactions from friends and you're willing to go through a centralized company anyway, it's cheaper to use an regular exchange.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U

Your theory is valid. I have also questioned the volume after the censorship action, but I believe privacy is subjective. It's like your window curtains; they keep your neighbor away, but then someone could have access to your CCTVs or phone camera and watch while you sleep, I believe many people coinjoin their coins just to "hide" from other people, not to hide from chain analysis/governments. Thus, using a government-friendly privacy (or lack thereof) service like Wasabi coinjoin might be an even better option.

Think about it this way: someone who wants to coinjoin to maintain a good level of privacy against friends, co-workers, customers paying them in BTC, or any other reason where the privacy you know isn't the center of it. To that someone, using Wasabi is probably a better option. They could think that since this service goes through a government filter, what comes out of it is going to be "clean" coins, making them safe for future cash-out.

On the other hand, if they use a non-government-friendly service, they could be "accidentally" or "intentionally" mistakenly identified as a scammer/terrorist or whatever. This is always a possibility as long as criminals use coinjoin, and many people believe in tainted BTC. Many people want to steer clear from anything gray—let alone black—so they may choose to use a government-approved service.

When I define privacy to myself, I take it as a whole package. It's myself against the whole world. I treat everyone else looking from the outside as an intruder. I believe you and many other privacy-oriented people define privacy the same way, but we can't assume that everyone thinks of their privacy the way we do. Many people are willing to KYC themselves to some random exchanges just to get an airdrop of some worthless coins. And the KYC process isn't just "write your full name" and off you go; they now take selfies, write some information on a piece of paper. Many of them won't mind sending their naked pictures to those CEXs but still might want to hide their coins from their wives, employers, or God knows whom.

Personally, I believe that eventually, the entire crypto space will be heavily KYCed. I don't have much hope in the crypto community to fight for their privacy. The majority of people invest in crypto to make a profit, and most of them don't appreciate all the beautiful things BTC has to offer them except to make them rich. So, I won't be surprised if all that volume comes from real users who believe it's completely normal for the government to spy on them. Mind you, these aren't all just regular users; even people like Peter Todd advocate for Wasabi, calling the Samourai team scammers and being fine with chain analysis spying on them, so go figure.
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
it seems like you are making an even wilder assumption thinking that everyone using Wasabi is a newbie jerk who doesn't care if their not-so-private coins become 100% KYCed.
Doesn't seem that wild to me. If you still believe Wasabi is a good option after the numerous lies, the incidents where their software was caught to be flawed, the blacklisting update and their cooperation with mass surveillance firm, then you're naive to think it's superior solution. If you are tricked into believing that funding blockchain analysis for the sake of your coinjoins is a clever choice, then you surely can be tricked into believing some sort of other nonsense for the sybil attack as well.

I personally hated the fact that they took this path, but the chainanalysis/censorship isn't a concern to many people
If chain analysis in a privacy-protecting software doesn't ring a bell to you, then I'm pretty confident that a silent sybil attack will neither.
hero member
Activity: 756
Merit: 1723
Crypto Swap Exchange
I do understand the anger and hate against Wasabi, I personally hated the fact that they took this path, but the chainanalysis/censorship isn't a concern to many people, in fact, their volume over the last year is higher than it was before the censorship, could it be fake? of course, but are there a dozen people out there who don't care about Bitcoin fungibility? indeed, is everyone using Wasabi stupid? I'd say no, should anyone use Wasabi? NO, are there better options? Yes.
And this is very mind blowing to me.

How do you explain this?  More than half of us who were using Wasabi before hate what they did and are not using their Wallet any more.  But the Volume is higher than before we stopped using it?

Makes me think about a few things, which are very broad assumptions but it is still a concern to me.  I am worried about things like Could the Blockchain Analysis partner of theirs be including a lot of their own Inputs so they could artificially rise the Volume to attract more people while also rising the chance of linking the rest of the users to their Coin Joined Bitcoin?

Back when they decided to do this Chainalysis thing the first thought I had was Politics.  I thought big names would come with big time money to drop into Wasabi and launder it all in a legal way.

In consequence I am still worried about a few things such as the above.  It makes no sense to see almost every body hating on Wasabi while their business prospers.  You would expect the opposite to happen to their business.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
That's quite of a big assumption to make.

It would have been an assumption if I said "only me and you trying to coinjoin this round", which I did not, it was merely an example to explain how user X could detect that user Y is being targeted in Sybil attack.

Quote
A sybil attack is obviously not an exclusive perk of Wasabi;

Great then, it shouldn't be used against Wasabi, unless there exists a valid proof that they are doing it themselves, which nobody has come up with yet as far as I am concerned.


Quote
You're also making the wild assumption that the remaining clients will be concerned about experiencing a sybil attack. Anyone choosing to use Wasabi after the extensive list of red flags would be the least likely to worry about being sybil attacked.

If the "remaining clients" are not concerned about their privacy then why use a coinjoin in the first place? it seems like you are making an even wilder assumption thinking that everyone using Wasabi is a newbie jerk who doesn't care if their not-so-private coins become 100% KYCed.

Also, all the research and money spent by competitors isn't enough? Have you seen how hard the Samouri team is trying to find the smallest flaw in Wasabi? it would cost them less to monitor Wasabi than it would cost Wasabi to launch continuous Sybil attacks.

I do understand the anger and hate against Wasabi, I personally hated the fact that they took this path, but the chainanalysis/censorship isn't a concern to many people, in fact, their volume over the last year is higher than it was before the censorship, could it be fake? of course, but are there a dozen people out there who don't care about Bitcoin fungibility? indeed, is everyone using Wasabi stupid? I'd say no, should anyone use Wasabi? NO, are there better options? Yes.

legendary
Activity: 1344
Merit: 6415
Farewell, Leo
Up to this point, you have only provided input and a blinded output (no Sybil attack is possible)
The sybil attack is an on-going process. If the coordinator forbids you from joining the round, with the excuse that you're "naughty", it gains the advantage to replace your potentially untraceable coins with traceable, to de-anonymize certain inputs; which are the victims of the attack. Then, it can repeat, with other victims.

So let's just assume it's only me and you trying to coinjoin this round
That's quite of a big assumption to make. In reality, you don't know anything about the people you coinjoin your coins. That's the reason we're discussing about sybil attack in the first place. If I knew by whom the round is consisted of, I wouldn't have to worry.

Note that I am talking about the possibility of the coordinator using the power that other attackers don't have to perform sybil attack, what you described in your previous post could be achieved by anyone, I know the maximum number of inputs in each round is x, I can register x inputs and perform the same attack, in other words, this could probably be applied to all conjoins coordinators not just ZKsnacks, so not sure why is this an exclusive criticism for Wasabi?
A sybil attack is obviously not an exclusive perk of Wasabi; it can potentially be executed on every peer-to-peer network. However, comparably to e.g., Joinmarket that's implemented resisting measures such as fidelity bonds, there is clearly an orders of magnitude difference. Not only does Wasabi not resist same like, but it requires approval from an entity that is incentivized to execute such attack.

You're also making the wild assumption that the remaining clients will be concerned about experiencing a sybil attack. Anyone choosing to use Wasabi after the extensive list of red flags would be the least likely to worry about being sybil attacked.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
And what's a "valid" input? Is there such a terminology in their repository?

Yes, anything that passes the input registration phase is valid.

Code:
private async Task MoveToConnectionConfirmationAsync()
{
using (BenchmarkLogger.Measure(LogLevel.Info, nameof(RemoveAlicesIfAnInputRefusedByMempoolNoLockAsync)))
{
await RemoveAlicesIfAnInputRefusedByMempoolNoLockAsync().ConfigureAwait(false);
}
using (BenchmarkLogger.Measure(LogLevel.Info, nameof(RemoveAliceIfCoinsAreNaughtyAsync)))
{
await RemoveAliceIfCoinsAreNaughtyAsync().ConfigureAwait(false);

It's probably worth a bit of logic in how the coordinator operates, ZKsnacks operates chaumian coinjoin structure, it runs through five main phases which are

Input Registration
Connection Confirmation
Output registration
Signing
Broadcasting

This could be further understood in the CoordinatorRound class

Input Registration: in this phase, the client would sent an input and a blinded output, this is where the "banning" is done.

You can see the old code was

Code:
var round = new CoordinatorRound(RpcClient, UtxoReferee, RoundConfig, confirmationTarget, RoundConfig.ConfirmationTarget, RoundConfig.ConfirmationTargetReductionRate, TimeSpan.FromSeconds(RoundConfig.InputRegistrationTimeout));

changed to

Code:
var round = new CoordinatorRound(RpcClient, UtxoReferee, RoundConfig, confirmationTarget, RoundConfig.ConfirmationTarget, RoundConfig.ConfirmationTargetReductionRate, TimeSpan.FromSeconds(RoundConfig.InputRegistrationTimeout), CoinVerifier);

They added a new dependency called "CoinVerifier" which is called by the "naughty" method you mentioned above, basically the Coinverfier class interacts with ApiResponseItem that gets the ban/approve from an HTTP response.

Now if you check the private asynchronous method called  Task MoveToConnectionConfirmationAsync()


Code:
private async Task MoveToConnectionConfirmationAsync()
{
using (BenchmarkLogger.Measure(LogLevel.Info, nameof(RemoveAlicesIfAnInputRefusedByMempoolNoLockAsync)))
{
await RemoveAlicesIfAnInputRefusedByMempoolNoLockAsync().ConfigureAwait(false);
}
using (BenchmarkLogger.Measure(LogLevel.Info, nameof(RemoveAliceIfCoinsAreNaughtyAsync)))
{
await RemoveAliceIfCoinsAreNaughtyAsync().ConfigureAwait(false);
}
Phase = RoundPhase.ConnectionConfirmation;
}

so before moving to the second phase of Connection Confirmation, all the filtering is done, your coins become invalid either due to them being "naughty"  or "Invalid",  let's just assume the input registration is invalidated for no valid reason.

Up to this point, you have only provided input and a blinded output (no Sybil attack is possible) since the coordinator did not receive an output from you, and you are not yet enrolled in a coinjoin, so if they want to Sybil attack you, they would need to sign the blinded output and send it back to you

If you pass this phase, the coordinator will now need to sign the blinded output and send it back to you with a new identity/UniqueId(still no Sybil attack or its detection is possible yet)

So let's just assume it's only me and you trying to coinjoin this round, you got your inputs registered and I got mine, we both got our blinded outputs signed and received our unique-Ids, we would now enter the Connection Confirmation phase, and whereby we both send our uniqeIds to the coordinator and we both know they are valid and the coordinator MUST accept them.

If the coordinator were to reject my connection confirmation it would be safe to assume that they are launching a Sybil attack against you (of course I don't know whom they are launching the attack against but having refused my connection while I have a valid unique id the proves that I have registered x input means they are doing the attack), there is no VALID reason for them to refuse my conn-conf, it should be accepted and after the timeout we need to move OutputRegistration phase, you can check the code to find that       Phase = RoundPhase.OutputRegistration; doesn't have any valid conditions of which they can reject you for "no reason".

This applies to the rest of the phases, if the coordinator accepted your input registration -- there is no valid for reason them to stop you from going forward, I am not saying they "can't" of course they can reject your connection confirmation or even claim that your output registration was invalid, they can even claim that you did not register your input to start with, but given that the code is open-source it MUST act as it says it does, otherwise, people/observers would see that they are being refused for no reason which means the code which is run by the coordinator isn't exactly what they say it is and/or, they are trying out some attacks.


If Wasabi going to sybil one input they put all other inputs in a different round. Very easy for them. And undetectable.

Round ID, Input count, current phase, time to next phase are all publically available, your claim would be valid if you register two inputs to the same round and they end up in different rounds, otherwise, how do you suggest doing that without anyone noticing? obviously, most users don't check all this info and just use the next GUI and set their auto-conjoin, but don't you think there are enough people (Wasabi rivals for example) logging every round detail to showcase how Wasabi is doing all of these claims? besides, whatever you suggested could be applied to all other Coinjoins that use a centralized coordinator, which is why I said "let's keep criticism" fair.

My main issue with Wasabi is the fact that their default coordinator and funding firm ZKsnacks censors transactions for no valid reasons.
Okay, but if they wanted to target individual UTXOs every now and then, that might be feasible, right?

It's always doable, I am just not sure about how feasible if enough people are observing these rounds and actually are spending time and money to detect such attacks (mainly their competitors), if you see all the research Samourai Wallet team does on Wasabi, you would probably guess that there are enough people watching them, of course tho, just because nobody caught them -- doesn't mean they have never done it.

hero member
Activity: 882
Merit: 5818
not your keys, not your coins!
[...]
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.
Okay, but if they wanted to target individual UTXOs every now and then, that might be feasible, right?

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.
From what I've heard so far, it seems to me that sybil-attacking from the coordinator side is still feasible, as long as it's not done on a massive scale.

That's a good last point, though; even if they weren't doing anything fishy, every Wasabi CoinJoin puts some extra money in blockchain analysis pockets. They might use that to fund more blockchain analysis research and development for new ways to deanonymize us.
jr. member
Activity: 34
Merit: 33

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.


If Wasabi going to sybil one input they put all other inputs in a different round. Very easy for them. And undetectable.

And no need to sybil every input. Every input is examined by BC analysis first. BC analysis say 'we don't care about this input, fully KYCed, user is tracked by other methods, whatever' then coinjoin as normal. BC analysis say 'gov want more info on this input' then they get sybilled.
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
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.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
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.


Quote
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.

hero member
Activity: 882
Merit: 5818
not your keys, not your coins!
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?
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
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.  
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
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.
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U

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.
legendary
Activity: 3458
Merit: 6231
Crypto Swap Exchange
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
legendary
Activity: 2170
Merit: 6279
be constructive or S.T.F.U
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.
Pages:
Jump to: