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

Asides from custody and trust in not keeping logs, I still stand by that assertion. It's just seems arrogant to argue today, because ChipMixer was a trust-requiring, single point of failure, that was taken down, and that the other solutions we now have are self-custodial.

And that's true. It is arrogant. These two properties are two important to overlook. However, if we do overlook them, coins sent to ChipMixer were not connected via blockchain transactions, and that greatly increases the anonymity set, because the analyzer has to take into account all UTXO in the blockchain with amounts 1 mBTC, 2 mBTC, 4 mBTC etc. This is clearly bigger set than all the outputs of a coinjoin.


There's nothing particularly wrong that ChipMixer did to this user, and to no other user. All of us had the option to withdraw chips. The hacker just had above average amount deposited, and withdrew it in the most inappropriate manner.

And in case you think ChipMixer did not warn against that as a practice, here are their best practices from web archive:

That is irrelevant. I have mentioned other users who have spread misinformation and vouched for services that offer substandard privacy and can possibly steal your coins and log your information. As someone whose opinion actually held weight amongst users it would only be natural for his name to come up as well.

---

https://bitcointalksearch.org/topic/--5286821

One of the rare times where you mention the custodial aspect being a drawback yet you still said it was better than coinjoin.


Here is a final one although I could probably find more by searching other keywords.

---

I have tried to avoid the drama and am not seeking for submission from anybody. I've only intended to engage in factual debate. My only problem is with mixers and the hypocrisy of those who have defended them despite the many problems involved with using them. Criticisms against Wasabi are also fair, since they are not without their own flaws, and people should be free to express their concerns. I am not for censoring, red tagging, and making false accusations which is what I have received when I have expressed views that inconvenienced several members.

Ideally and on paper, that's the very perfect situation. But practically, it's not easy to boot-strap enough liquidity. But I do believe that the more trustworthy and influential members of the BitcoinTalk community should organize us plebs and run a coordinator.

Plus the community should probably run more than one in my opinion. Some of the services that are advertising in the forum should probably be involved as well.

There will be some sceptical views even though you are stating for the record you did not exploit any vulnerabilities.

And yes, running a coordinator for offering a decentralised service might make sense and running coordinators through BTCPay server and the wasabi coinjoin coordinator plugin is a simple process to set up.

Having said that, what needs to be considered is if various agencies start getting involved accusing the coordinator provider of money laundering (and other illegal/nefarious conduct) then this will cause many problems as they try to defend themselves and their name.

Probably, more than a year has passed an there is still an ongoing discussion around this service? C'mon, it really has to come to an end.

Kruw, as I remember, there was an issue with the fact that Wasabi Wallet partnered with blockchain analysis company and that will always logically be an issue. Imagine, working on a safe airplane and at the same time funding a Surface-to-air missile development, that's the analogue of Wasabi, a privacy oriented company and tool partnering with Blockchain Analysis company.

I completely agree with you!

He really got under your skin, didn't he? Bringing him up even a year after he's passed away.

I always remember myself recommending coinjoin and Monero over to custodial mixers, and there's nothing in the quoted text that suggests otherwise. But, feel free to dig up the forum more and prove me wrong.

My friend, I can also point out issues on coinjoin clients that said they were providing privacy when they actually weren't when the user did all sort of dumb decisions, like the KuCoin hacker. For example, I can also point you out to whirlpool user deliberately consolidating toxic change with private coins. It could also be very possible that WabiSabi coordinators have de-anonymized coinjoin in the past, abusing this recent reported vulnerability, with the user being completely unaware of the spying.

Please refrain from provoking me in a discussion about which client software has the highest number of incidents involving people being caught for "misusing" it.

---

This ongoing drama has to come to an end. Right now, it feels like you're trying to make me submit, just as others (including myself) have tried to make Kruw submit. I'll admit that I've said things in the past that were incorrect and have spread misinformation about WabiSabi (the protocol). Similarly, Kruw has said plenty of foolish things on this board, and I'm sure he's aware of it too.

I'm not asking anyone to forgive the things that have been said during this conflict; there have been plenty of unforgivable remarks from both sides. However, can we set aside our egos? Nothing good will come from continuing this. WabiSabi is an excellent protocol, and while the team is one big problem, it's open-source, meaning we can improve it. Bitcoin's need for privacy is more important than either side seeking "redemption".

What do you say?

Many people downplayed the risks and lied to users about how these mixers work.

o_l_e_o called ChipMixer low risk and secure.


You called Chipmixer better than coinjoin and repeated the time travel myth time and time again.


We know this is false because the KuCoin hacker reused the same deposit address and when they consolidated their chips we were able to see that in some cases they were just receiving the same coins they had just deposited. Chipmixer was especially bad for larger amounts because they lacked the liquidity to give you enough pre-funded chips. In a coinjoin if there isn't enough immediate liquidity, you either get toxic change in return or you continue mixing until all your funds are private, they don't lie to you and tell you your coins are private when they aren't.

It would be in the "privacy" category rather than the "critical" category. I awarded a small bounty to the researcher who reported it.

Would you classify the recent report as a critical bug? The coordinator being able to de-anonymize coinjoin.

• It always bares a risk to use a custodial service.
• Many of us do warn about these risks.
• None of us has ever portrayed custodial mixers as the absolute privacy solution that carries no tradeoff, in comparison with Wasabi.

I’ve witnessed far bigger vulnerabilities with custodial mixers, however, since there are so many members being paid to advertise these scam websites on altcoinstalk this will never receive the level of acknowledgment it deserves.

I also want to get a better understanding of the issue. "Tagging" is mentioned in the WabiSabi whitepaper in section 6.2, but it's very math heavy and I wouldn't know where to begin in regards to comparing it with the code implementation. The attack would involve a malicious coordinator, the report from TheRage mentioned the researcher tested 3 coordinators which did not reveal any were exploiting it.


I suppose I should say for the record that I have not exploited any tagging vulnerabilities with my coordinator. As always, I want to remind people that they should run their own coordinators as well to help decentralization, market competition, and privacy self-education.

I would like to get a better understanding of the issue that was affecting Wasabi Wallet versions 2.2.1.0 and below and could be relevant to subsequent releases. Without reading posts about detailed specifics related to why it can or cannot happen, theoretically is it possible for Wasabi Wallet to log non-anonymous data from their users?

Kruw did make a comment about this when I asked earlier but is the answer still valid?

My claims about the protocol hold true, but I've never claimed that clients implementing the protocol are bug free. There's plenty of bugs in Wasabi, and Github is used to track their priority.


Since I'm not a programmer, I'm unable to identify or verify code level bugs, I can only test reproducible bugs. As such, I don't want to misalign incentives and push the burdens of bounty verification to the developers who are maintaining the project.

For general guidelines, if the bugged scenario requires users to change multiple defaults to trigger it, it's less likely to be high priority for fixing or a high value bounty. However, these classes of bugs should be straightforward and worthy of bounties:

Critical:

2.5m sats - Bugs that allow remote theft of funds
1m sats - Bugs that cause funds to be destroyed

Privacy:

500k sats - Bugs that reveal clearnet IP instead of Tor (when performing an action tied to your coins)
- Bug fixes or design changes that optimize privacy with no additional tradeoffs involved may be awarded bounties on a case by case basis

Graphical:

- No bounty for discovery, bounties may be awarded for PRs that fix UI bugs on a case by case basis

Any critical bugs should not be reported to me- they should be disclosed privately to the maintainers.

Great attempt at quoting a single sentence from my post and trying to sweep the rest under the rug. It didn't work though.

Here is what you should have focused on:

- The software you and your team marketed as the "ultimate privacy tool" was vulnerable for a very long time. It might still be vulnerable today and in the future because the fact that it's open-source means nothing. It was open-source while it was vulnerable as well and who noticed it? How long was it vulnerable before someone found out and how much harm did it cause while being vulnerable? You have admitted yourself that you have no coding skills, so your explanations aren't worth anything.

- The protocol requires trust. Trust that the coordinators won't try to deanonymize you.

- Each time you wrote that Wasabi and coinjoins are trustless and how the coordinator and blockchain analysis can't obtain any information about users, inputs, and outputs, you lied.   

- You and your zkSNACKs buddies deliberately tricked customers into using a flawed tool, whose privacy depends on the trust of the coordinators. And you are not to be trusted.

---

It's becoming very clear why you are offering a free coinjoining service. You don't need fees from the users. You can get your funding from other service providers and (state) actors who would be interested in purchasing the data from you. The data, which we now know can be deanonymized.

This is just one vulnerability detected in the protocol, and it was detected too late. How many more malicious code snippets and bugs do you have that will only be detected in the future or perhaps never?

Yes, that's the good with being open-source, but I hope you acknowledge how ridiculous it now sounds to claim that it is completely resistant to Sybil attacks and how absolutely invulnerable the client is. All these assertions were just invalidated with this recent report.

And we frankly don't know if this vulnerability has ever been exploited before. We're just guessing.

I'd be interested in this. How much are you willing to pay? And define "serious bug".

---

The protocol is pretty decent, if you read the paper. It's theoretically one of the best approaches to implementing coinjoin. It is the team that puts this theory into practice which cannot be trusted, unfortunately, judging by their behavior, as revealed in the past, and their demonstrated lack of competence.

MALICIOUS Coordinators?!  But, I thought it is about impossible to fall for such a malicious one considering it would be almost obvious to the consumer if they are targeted!

-----

It is your fault, did you not read what Kruw says?  No Trust is required, or did you not check the source code properly before using Wasabi?

-----

The question JollyGood asked a while ago is more relevant than ever.  And the avoidance in the answer provided by Kruw is even more suspect than ever now,

I'm happy to pay out a bounty for any serious bugs discovered in the code.

''T0tal privacy'' and an0nymous bitcoin my ass  
How convenient that coordinator can deanonymize the user.... sure it can happen because this is centralized control.
After this incidents I have to say that I don't trust WabiSabi protocol and their lead architect Yuval, I am sure there are more hidden ''bugs'' in code.

Exactly. The ability to test whether a coordinator is exploiting an active vulnerability is somewhat of a silver lining to the existence of the vulnerability. Another example of this was with the inflation bug in Bitcoin that was fixed in 0.16.3. Since this bug wasn't exploited by miners at the time, it provides some circumstantial proof that entities who aren't normally in a position of trust are able to wield a position of trust responsibly once a vulnerability places them in that position.

Obviously, we should always strive for bug free code and incentive aligned protocols, but it's a small advantage that would allow users to reallocate coinjoin liquidity to honest coordinators or miners to reallocate hashrate to honest pools.

Not being specific to this case as I am not familiar with the situation but in the general sense there is always the dilemma businesses face when they become aware of a problem and then have to make a decision to either announce it in public or to try to suppress it on order to protect themselves from the negativity that would be directed towards them.

If it was something that was left there for nefarious purposes then their plan has failed therefore that is a positive to look at.