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? 👀
quoting
nevent1q…7s5x
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:
* https://github.com/orgs/WalletWasabi/discussions/13661
* https://github.com/orgs/WalletWasabi/discussions/13796