WasabiWallet / Wasabi Wallet is on Nostr

Open-source, non-custodial, privacy focused Bitcoin wallet for Desktop

Last Notes

2024-10-17 14:41:09

We've redesigned our network isolation code (Tor integration)!
Originally, .NET lacked native support for routing HTTP traffic through Tor, so we built custom solutions. Over time, this became unsustainable, requiring us to manually implement many new low-level features like redirects and compression.
Now, with .NET 6’s native SOCKS proxy support, we've switched to a more efficient HttpClient. This simplifies our code, improves performance, and makes it easier to implement new features without headaches. It also improves clarity on how Tor integration works and drastically reduces the potential for errors.
Better building blocks are key to keep improving Wasabi!
https://m.primal.net/LYmP.png

2024-10-17 07:19:51

- reply

Thanks for the feedback! Wasabi currently doesn't support any kind of localization. Only English, USD as fiat currency, American formatting standards. It is definitely something we're looking into, but it will take time.
For the amount formatting specifically, we use the . as a separator for decimals and a thin space for thousands separation. Even if localization would be much better, the complete lack of comma avoids possible confusion.

2024-10-16 03:22:41

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. ⚡
https://m.primal.net/LXKJ.png

2024-09-21 04:42:39

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 🚀

2024-09-20 15:45:34

- reply

I obviously wanted to say "silent", not "release". Sorry!

2024-09-20 11:54:06

- reply

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.

2024-09-20 00:32:15

🚨 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.
https://m.primal.net/KvGi.png
🚀 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.
https://m.primal.net/KvGe.png
⏫ 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.

2024-09-19 03:13:32

## 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!

2024-09-16 18:00:54

- reply

Should be fixed

2024-09-16 16:55:44

- reply

Done, we were waiting for an invite code to test the new @npub1get…0nfm Hub

2024-09-16 14:52:54

- reply

Thanks, done!

2024-09-16 12:31:09

- reply

Joined at the same time 👀

2024-09-16 01:05:31

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