thats cool and all
but what people *actually want* is to be able to personally verify the privacy guarantees they are paying for.
how does Wasabi prevent Sybil attacks again? 👀
Wasabi dev here.
Wasabi development has been focused on guaranteeing the survival of the wallet almost exclusively since zkSNACKs abandoned the project. This means changing an originally centralized, trusted, client-server architecture to a standalone, trustless piece of software with decentralized services run by volunteers. In other words, the goal is to completely redesign Wasabi's architecture to eliminate central points of failure and protect Wasabi users and volunteers.
However, users need a reason to upgrade their Wasabi clients other than a "better architected" wallet; they would upgrade only if Wasabi has something new and better to offer them than their current version. That's THE reason why Wasabi releases include support for receiving Taproot, Silent Payments, manual coin selection to spend, SLIP39, support for new hardware wallets and others alike—things that are not a priority at all but allow the development to move release after release, removing dependencies from centralized services and achieve eventually the biggest goal.
Small and almost insignificant changes like allowing users to choose the provider for the fee rate and USD/BTC exchange rates, removing the concept of coordination fee, separating the coordinator as an independent service that can be run by anyone and allowing users to configure a coordinator and set its parameters, optimizing the coordinator and backend to run on small computers or cheap VPS instead of requiring monstrously big and expensive hardware, allowing the coordinator to run simply with an aggressively-pruned Bitcoin node, removing the client dependency on tens of centralized APIs—these kinds of changes are the ones that really matter for Wasabi's future.
Wasabi innovates by making the wallet more resilient while adding nice features. But resiliency is THE feature anyway, so in the next version we are going to release Shamir Secret Sharing backups but also a mechanism to allow Wasabi to detect new releases, download them and verify them without having to trust on GitHub's goodwill (because we don't trust GitHub or any other centralized big tech service provider—yes, yes, we use Nostr for that). The next version will be the first in which Wasabi will be able to synchronize without having to connect to any central server, just connecting to an RPC node with compact filters. The next version removes the concept of backend; instead, there is only an indexer, a server component that provides Wasabi compact filters and/or standard BIP158 filters. This is a super cheap piece of software that can take standard BIP158 filters from your node, cache them, and provide them to clients in a way that Wasabi clients understand. The next version gets filters from RPC, blocks from RPC, fee rates from RPC, and broadcasts transactions using RPC, which allows users to use Wasabi without needing to use anything from anywhere or anyone.
There are tons of things that have been redone, redesigned, or changed completely just to facilitate the way to the final goal. It's hard to enumerate them all: a complete redesign of the Tor integrations, a complete change in the technology of serialization, a complete redesign of the Bitcoin node integration, a redesign of the Wasabi configuration (WIP), include the backend and the coordinator in the linux release—all while removing more than 25,000 lines of code.
Very few can compete against Wasabi in this regard because Wasabi is an idea, an ideologically-driven commitment of volunteers doing what they think must be done and risking what nobody else wants to risk in order to do good.
Update: here you have what guides the development:
Discussion
Let's go by parts:
* Wasabi only works with free coordinators, those which have no way to charge you any fee. This means that you are not "paying for" anything.
* In Wasabi, there is no way to restrict the participation of others or to degrade the anonymity of others. This means that, for example, if in a coinjoin round there are 10 participants with a total of 40 inputs and an attacker enters with 400 inputs, the attacker cannot deanonymize any of the 10 participants. The only "damage" that the attacker is doing is creating the illusion of a higher anonymity score because for an external observer (other than the attacker) the anonymity score is indeed higher.
wait
what prevents 9 of the other participants from being an Adversary?
You assume that there is one user and all the rest are just different identities of the same adversary but given the adversary cannot prevent others to joining, that scenario is extremely unlikely.
yeah
when there's zero barrier to entry, how do we prevent the Adversary from sybiling the rounds at will and degrading everyone's privacy?
I have explained that above twice. Now, it is your time to understand. It seems to me that you don't want to understand.
So if I understand correctly there is nothing preventing nine of the ten participants from being a single entity
You just think it's unlikely that someone would flood the rounds to denigrate anonymity
Do I have that right?
No. You should prevent somehow other honest users from participating, what you cannot do.
since theres no penalty to flooding or any bar to entry at all,
users entering a CJ round are *trusting they are building a transaction with other honest users
maybe its a good trust assumption
i dunno
but thats what it is
Ok. Please sybil attack the kruw's coordinator and let me know the results.