Remember the Wasabi Vision

[lontivero]

Wasabi's survival goal was achieved. Now what? Well, we have spent five releases fixing things, and for that reason we have forgotten the big picture, the vision. I will try to re-establish the vision here, but before that, let's talk about the new paradigm: AI.

Artificial Intelligence

There is not a single day in which we don't read about a new big hack. It seems that absolutely everything is compromised. At the time of writing, BTCPayServer users' wallets are being drained and Wasabi users are clearly a target. We have to do something about that; we cannot continue developing as before.

Security focus

During the last two years we have removed lots and lots of things, from the whole backend (which was reduced to a simple indexer and finally removed completely in favor of the website), to the Password Finder, Swagger, Wallet backups, Kitchen, MaxSuggestedAmount, CoinJoinIdStore, the coordination fee mechanism, Payjoin, Local Node integration, and BitcoinKnots. Who knows how many more things evaporated from the solution. Removing things, especially if they are stupid, is a great service to the project and an even greater service to the security of the funds.

The things that were removed were identified about four years ago and listed in the Wasabito commit history: https://github.com/lontivero/Wasabito/commits/master/. That's why it was easy to remove them. The good part is not only that there are fewer things to maintain, but also that removing them dropped the number of problems and bugs by a lot. For example, before taking over the project I spent many, many nights awake because the server went down. Fortunately, those days are over. The same happened with the broken wallets, the Payjoin implementation that had many bugs, and the coordination fee mechanism that didn't allow me to sleep in peace.

Nobody has ever complained about any of the removed things, and Wasabi is much better software now. So the old saying "you cannot improve software by removing features" is not always true.

In the era of AI, we need to reduce the attack surface as much as possible by eliminating complex concepts and by designing (or redesigning) the software in a safer way.

• Move the private key material and its management out of Wasabi. Wasabi shouldn't know the private keys or any secret material.
• Minimize dependency on external sources. Absolutely everything we receive from the external world should be treated as poisoned. Malicious nodes can fool us (the RBF vulnerability was because of this), an exchange rate provider can fool the user into paying more, a fee rate provider can fool us into always paying a unique fee rate, etc. This obsession was always with us, but only against the coordinators. Now it has to be against absolutely everything. All inputs must be not only validated but also analyzed and sanitized.
• Minimize trust in external programs. This sounds too extreme, but I think we are in extremely difficult times.
• Minimize the number and origin of third-party packages.
• Disable everything by default. I mean it: disable RPC, disable scripting, disable coinjoin, disable connections to external sites, disable everything.
• Make everything read-only by default, even the code.
• Make sure to use the correct users with the right permissions for each component.
• Use AI to review security aspects of PRs.
• Do not add unnecessary features, especially if they are stupid features that require big changes.
• Change the focus from creating to reviewing and testing. We need automated tests through the UI, which we don't have, and tests for real coinjoins in regtest, which we don't have either.

Note: Remember that the goal is to have Wasabi as an always-running service. That means everything must be limited as much as possible.

Vision

Finally!

The vision is to become the privacy solution for users at a lower cost. Ideally, everybody should be coinjoining in one way or another. This means we need to keep making Wasabi faster and less resource-hungry. We need to allow the creation of lighter clients (and mobile clients), as well as cheaper and more reliable coordinators.

The actions to achieve that have been discussed many times, but I think they were never explained well enough. Here is the list:

Multiparty transaction signing with hardware wallets

We need to make Wasabi a read-only wallet in the sense that it shouldn't need to know the secret keys. We can already do that with @kravens' PRs, but we need to remove the secret material from the wallet and move it to a different component (a Wasabi Signer) with an interface identical to a physical hardware wallet. Think of it as a software hardware wallet that receives a PSBT, checks all the rules, and, if everything is alright, signs it and returns the signed PSBT. This way it is much safer to run Wasabi on a VPS or as an always-running service.

We also want to allow users to coinjoin with hardware wallets because that can prevent one of the most absurd behaviors of whale users: sending funds to Wasabi, participating in lots of coinjoins, and then consolidating everything and sending it back to their hardware wallets. This problem has never stopped happening in eight years. Of course, the problem is that people use Wasabi as a mixer instead of using it as their day-to-day wallet, but by allowing coinjoins with hardware wallets we can minimize it.

NWabiSabi native library

The native WabiSabi library is not only much faster and less resource-consuming, but also allows other wallets to use the WabiSabi protocol and cryptography. Ideally, all wallets should allow users to pay in coinjoins, and that can be done by creating bindings for the library and a demo implementation.

The native library uses a stricter set of rules than NBitcoin, and we should go in that direction. Once we have dogfooded it for long enough, we should push others to allow payments in coinjoins (a better name would be private payments).

Make Wasabi a service

The Wasabi UI is heavy in terms of memory and CPU, but the daemon is not. The idea is to run the daemon as an always-running service. When the UI application is launched, it connects to the daemon using WebSockets, SignalR, or whatever other IPC technology and consumes its services. This way our wallets are always synchronized and ready, and we can start coinjoining and close the UI, or enqueue payments and go to sleep.

To achieve this, it is necessary to separate the daemon from the UI. That would allow us to create multiple clients, run the service wherever we want, and connect our Wasabi Desktop to any remote daemon.

Wasabi Mobile

We need to do something with the work that @wieslawsoltes has done, because it would be a pity to lose all that effort and knowledge. We don't have to have the full thing at once. We can have an APK, distribute it via Zapstore, then see how to publish it on the Google Play Store, and continue with Apple later.

Update the WabiSabi protocol

Although this is something for 3.0, we need to solve a couple of pending issues with the protocol by committing to missing fields and finding a solution to the possible tagging derived from not checking the round ID after each communication.

Allow Wasabi Scheme to broadcast transactions

I would delay this development because it is dangerous, like monkeys with shotguns. The question is how to enable automation without opening a huge security hole.

If you have never heard about this before, it is a scripting language that allows you to specify what you want the wallet to do. It is the most powerful feature in Wasabi, but also the most dangerous. Currently, scripts cannot sign, send, or broadcast transactions.

Receive Silent Payments

I am not against this, but it would reintroduce the need for a central server, something that took us two years to remove.

Derive keys for coinjoins that never reuse

This is a must. Unfortunately, it conflicts with Kravens' PR and Trezor's SLIP-25 derivation path. Anyway, this must be solved.

[Coinjoiner21]

but we need to remove the secret material from the wallet and move it to a different component (a Wasabi Signer) with an interface identical to a physical hardware wallet.

I agree with this. It'd allow people to use Wasabi for cold storage funds.

I am not against this, but it would reintroduce the need for a central server, something that took us two years to remove.

What would be nice is for Bitcoin nodes to serve the necessary data for light clients, but I'm afraid that it is not a priority for Bitcoin Core: bitcoin/bitcoin#28536. I hope it doesn't take many years.

I would also rather not have a central server again, Wasabi feels a lot more decentralized now.

[kravens]

I've been showing people the hardware wallet coinjoin signing and my mobile "companion" iOS app on my phone. People are interested in both, but particularly excited about a Mobile GUI that safely connects to a Wasabi daemon running on a server or always-on desktop.

With hardware wallet signing, the questions are which models are supported and if they can use official firmware (only Trezor T, Safe 3/5 at this moment). I'd like to know more about why the Trezor derivation path is not compatible with the never-reuse keys idea.

[kravens]

Graphic with on the left side the current system architecture and on the right the vision we have for Wasabi 3.0: