Wasabi has the specificity of having to display all kind of amounts, as Coinjoin participants can have large pockets but also receive outputs quite small.
This is why a design working both for big and small amounts have been chosen, without cleaving with a settings were both sides would have drawbacks. We currently group digits by 4 and it creates a lot of visual fatigue while using the wallet, not with this new formatting.
After lot of tests, we noticed that this format is working really well specifically because how easy it is to read as decimals or as sats. Because the industry can't yet decide between BTC and Sats, displaying both at the same time makes real life usage much smoother.
We are really curious about feedbacks after release, and will try to actively collect some!
While many actors have already adopted this format, we were inspired by this excellent tool by nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3
How should BTC amounts be displayed? 🤔
In our next version (coming soon), we’re rolling out a fully redesigned amounts formatting throughout the wallet that we believe should set the industry standard.
It’s now much easier to read, no matter the screen or whether you’re dealing with small or large amounts. Plus, BTC/Sats conversions are instant. ⚡
v2.2.0.0 was a special one for Wasabi!
After countless hours revamping our procedure, this release was the first to be fully automatic 🤖
This is a major step forward, allowing us to ship new features and fixes much faster. Exciting times ahead 🚀
I obviously wanted to say "silent", not "release". Sorry!
Sending to a release payment address is on our middle term roadmap, you can expect it in not too long. Receiving however not anytime soon.
🚨 New release 2.2.0.0 is out 🚨
🥕 Taproot receive addresses
🚀 Faster transaction broadcasting
🔍 Help to setup and find a coordinator.
⏫ More accurate CPFP fee estimation
📉 Safer protocol
🪲 Backend optimizations
Release notes & Download: https://github.com/WalletWasabi/WalletWasabi/releases/tag/v2.2.0.0
🥕 Taproot receive addresses
Users can now choose taproot when generating a new receiving address. Spending a taproot input is 16% cheaper compared to spending a native segwit input. Users aren’t the only ones that benefit - Bitcoin nodes can verify taproot’s signatures faster than legacy ones, so the entire network gets a little speed boost.
🚀 Faster transaction broadcasting
A more sophisticated transaction broadcasting mechanism was introduced to make the process faster. Transactions are now broadcast to multiple nodes in parallel (through the Tor network) and fail more quickly if the transaction is rejected by the network. Users who upgrade will notice it now takes half as long to send their coins.
🔍 Help to setup and find a coordinator
A new message is now shown when no coordinator is configured, along with some help to understand how to find and setup one.
⏫ More accurate CPFP fee estimation
The CPFP feature now takes into account the fee paid by the parent transaction. In previous releases, the child transaction assumed the parent paid 0 sats in fees, and thus always overpaid for the speed up.. This improvement will be especially significant in high-fee environments, where the CPFP feature is most useful!
📉 Safer protocol
In order to avoid introducing unknown incentives and to limit risk to users, the coordination fee concept has been removed. Only coinjoin coordinators that don't charge any coordination fee continue to be supported. Read more: https://blog.wasabiwallet.io/killing-coordination-fee/
🪲 Backend optimizations
Users who run a Wasabi backend can now do so with a pruned node and significant CPU/RAM savings. This makes hosting a backend much cheaper and helps to decentralize this component which Wasabi clients still depend on.
## The cost of trustlessness and why we are killing the Coordination Fee concept
This article is the first in a series to be published on Nostr and our blog that aims to explain our decisions and trajectory by clearly presenting technical aspects of our implementation of a Bitcoin privacy preserving wallet and the WabiSabi Coinjoin Protocol.
Estimated reading time: ~10 minutes
Best read on a Markdown compatible client
### Being trustless and privacy preserving
As Sjors Provoost notes in the introduction to [Bitcoin: A Work in Progress](https://www.btcwip.com/), "keeping open-source software free of money-stealing bugs" is an exceedingly difficult task, especially when such software handles funds. Potential exploits in code are visible to all, as are patches awaiting deployment.
For Wasabi, the challenge extends further, as clients participating in coinjoin must follow a coordinator's lead—a third party whose code cannot be verified. We rarely break compatibility or force updates, meaning users on vulnerable versions will always exist if an exploit is discovered.
Wasabi has consistently been designed to empower clients against potential bad actors:
* Reproducible builds
* Minimal information transmitted to third parties (backend, coordinator, fee providers, etc.)
* "Smart client, Dumb backend" architecture
The complexity involved in building a trustless system is both underappreciated and staggering. Trustlessness invariably comes at the cost of user experience, and these suboptimal workflows must be carefully refined to remain competitive against privacy-degrading or trust-based alternatives.
A prime example of this trade-off is block filters. While alternative wallets allow users to see their balance instantly by connecting to an Electrum server or similar backend solution, how do you retain users when your software first requires them to download 2.6 GB of filters, then download each relevant (or false-positive) block using the Bitcoin peer-to-peer network? To lighten this problem, significant resources have been invested in refining our synchronization process to optimize and ensure the privacy gain is worthwhile for most users.
Clients still need to receive some information from the coordinator: round start times, phase durations, mining fee rates, etc. This information is used to compute the round ID, which clients then use to build and verify everything happening in the round. Two clients receiving different parameters therefore cannot participate in the same round, ensuring a malicious actor cannot mine information by selectively sending different round parameters.
### Why the coordination fee concept is not a fit here
The coordination fee rate is a field provided by the coordinator and included in the round parameters. However, this field is unique, as it involves a non-standard agreement: the client must pay this fee only once (concept of free remixes). This is central to how the wallet functions: the client automatically participates in rounds until reaching a certain privacy threshold. If the rounds don't provide privacy, the client will continue to coinjoin indefinitely. Therefore a coordinator not offering free-remixes could create fast rounds not providing privacy and drain its users. We identified this problem, but the time it took to deploy a mitigation led to the only occurrence in our project’s history that some users funds have been exploited. For more details: https://github.com/WalletWasabi/WalletWasabi/discussions/13249
Free remixes are not the only "workaround" implemented in our client to improve the coordination fee system. Another crucial case for proper user experience is the "1-hop doesn't pay" rule. This means that if a payment is made using a coinjoin output and this payment produces change, the change doesn't incur another coordination fee. This rule is essential because clients don't control the size of their outputs. For instance, a user might receive only outputs of 1 BTC but need to make a payment of 0.1 BTC. The resulting change would not be private and would need to be remixed. Without the "1-hop doesn't pay" concept, this would result in paying the coordination fee again. Like free remixes, this rule is not enforced by the WabiSabi protocol. To be protected against coordinators that might not offer this "fee grace," clients would need to carefully select inputs for payments to minimize change value, sometimes at the cost of privacy.
In summary, the coordination fee relates to the implementation layer, and free remixes are not enforced by the [WabiSabi CoinJoin Protocol](https://eprint.iacr.org/2021/206). The protocol paper mentions it only as part of Wasabi's implementation. The client must trust the coordinator to allow its inputs into rounds indefinitely after the initial payment. A coordinator could decide against offering free remixes, in which case the client must trust it to produce rounds that provide substantial privacy, at least worth the cost.
In other words, the coordination fee concept involves an element of trust. It creates an incentive for the coordinator to act maliciously and forces the client to be highly discerning in recognizing when the coordinator might be attempting to extract more money than it should.
Resources could have been invested during the zkSNACKs era to build a guaranteed risk-free implementation of the coordination fee rate and free remixes concept. However, because the only coordinator used at the time belonged to the same entity funding client development, this type of development was not prioritized, as we knew this coordinator would not breach trust.
This is no longer the case, and the project's trajectory has changed significantly: resources are now extremely limited, and we prefer not to allocate precious developer hours to ensuring confidence in the coordination fee rate concept. Instead, we choose to allocate these resources to increasing software resilience, improving maintainability, and delivering impactful updates, such as the one coming in the next few days... stay tuned!
Done, we were waiting for an invite code to test the new nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm Hub
This Nostr key will be used by the Wasabi Wallet team to give updates on the project and provide some technical details.
Verify authenticity:
NIP-05: nostr@wasabiwallet.io
Github: https://github.com/WalletWasabi/
X: https://x.com/wasabiwallet/status/1835484240802157032
Website: Nostr icon on the left navbar