What to do for v2.9.0 and beyond

[lontivero]

Wasabi Wallet v2.8.0 will be the latest Wasabi version with a client-server architecture, in fact we could say that v2.8.0 will work with a bitcoin rpc only --local or remote. However, for those who don't run a bitcoin node, Wasabi still depends on somebody else's rpc server and that's why we cannot consider it completely independent of a server.

The ultimate goal for survival phase is to make wasabi run without any server, which currently is possible to implement thanks to wasabi is finally 100% bip158 compatible. By getting filters from the bitcoin p2p network Wasabi will be able to operate completely independent. This means that even for those that do not have a bitcoin node, Wasabi will work perfectly well. For those who have a bitcoin node Wasabi will work even better. That's thanks to the redundancy chain of fallback mechanism we built wasabi around.

In summary: BIP 157 as fallback mechanism for getting filters.

---

A lighter-weight Wasabi mode could be also welcome and could prepare the soil for a mobile version. Wasabi was designed with the mindset around multiwallet support where wallets are resync often, that's why Wasabi stores compact filters and downloaded blocks for future usage. Resync-ing was the way to repair broken wallets caused by bugs in the software, that's why once the software was fixed, resynchronizations become less frequent. In fact, I would argue that most users never resync their wallets. In that case, keeping gigabytes of filters and blocks makes no much sense anymore and can be removed. OSes without persistent storage and platforms with low storage would be the most benefitiaries.

---

Unification of send workflow. Send, Send in coinjoin, Send to may must have a unified UX which has to be massively simplified.
Payments in coinjoin should be improved to select coins in a more clever way.

---

Fix anonymity score and labels. We have a serious problem here which I have already explained before: https://github.com/orgs/WalletWasabi/discussions/14103

We must fix this thing before doing anything else that involves privacy-based decisions such as coin selections because otherwise the results will be unexpected.

---

Check other participants' ownership proofs. After two years we have been moving Wasabi in the direction of using a bitcoin node RPC instead of a custom backend and we have seen how users started (struggled) to connect their Wasabi to their own Bitcoin nodes. We can now assume that many users can finally check the existence of other participants' utxos and verify the ownership proofs. The first step is to reintroduce the ownership proofs as part of the wabisabi status responses and then verify them.

---

Separate Wasabi daemon from UI. Wasabi should run as a service/daemon all the time and not as a desktop wallet that we hide when the user tries to close it. In fact, it should be a tiny, low resource (low cpu, low memory, low bandwidth) service that receives a compact filter every ~10 minutes, some information about the existing rounds and nothing else, except when it is mixing of course.

An always running Wasabi eliminates many problems such as waiting for synchronization and keeping Wasabi open during payments in coinjoins. An always running/always synchronized wallet not only improves the user experience but also allow new powerful features while make making extremely ugly things like sleep-prevention and the single-instance checker unnecessary.

It worth noticing that the new Scheme-base rpc interface can help a lot in implementing this concept. This is why the Scheme capabilities should be extended.

---

These are just a few ideas to set the direction which was shared in 2022 as Wasabito https://lontivero.github.io/Wiki/html/wasabi/wasabito.html

[Kruwed]

In summary: BIP 157 as fallback mechanism for getting filters.

Absolutely.

Unification of send workflow. Send, Send in coinjoin, Send to may must have a unified UX which has to be massively simplified.
Payments in coinjoin should be improved to select coins in a more clever way.

#8588 and #9947 would be a huge help for this. The process of checking the anonymity score of your UTXOs and then adjusting your anonymity score target setting is a big hassle.