Being trustless and privacy preserving

As Sjors Provoost notes in the introduction to Bitcoin: A Work in Progress, “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

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. 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

The post Why are we killing the Coordination Fee? appeared first on Wasabi Wallet - Blog.

Since the release of Wasabi 2.0, many users have told us that they felt that hardware wallet integration had been put on hold. They were somewhat right. WabiSabi has made so many changes to the way coinjoins work that it has required almost exclusive focus for the past two years.

Fast forward to April 2024, WabiSabi coinjoins have largely stabilized and major performance improvements have been made to block filters. Because of this, active work on hardware wallet integration support has resumed.

In 2.0.6, two new wallets were added to Wasabi’s list of supported hardware wallets: BitBox02 and Blockstream Jade. 

With the latest release (2.0.7), we’re announcing that the newly released Trezor Safe 3 hardware wallet with secure element protection is now compatible with Wasabi Wallet. 

If you want to know all the details about this integration, keep reading. We will talk about what exactly is supported in this integration, how to use your Trezor with Wasabi, and finally how you can coinjoin directly from your hardware wallet using Trezor Suite. 

Why the Trezor Safe​​ 3?

The Trezor One and Model T do not rely on secure elements for protection, making them vulnerable to physical security attacks without the use of a passphrase. 

The Trezor Safe 3 introduces Secure Element Protection (EAL6+), and combined with a device-entry passphrase, it provides bulletproof security. 

It also features Trezor’s open-source design, on-device transaction confirmation, and an intuitive user experience. And as with all Trezor hardware wallets, you can use Shamir backups for added security. 

The most surprising thing about Trezor Safe 3 is how affordable it is: just $79 USD. If you don’t already have one, get yours here. 

What is Supported in Wasabi’s Latest Integration?

This integration is very similar to the existing integration for Trezor’s One and T models. Wasabi only uses one device management component, HWI (Hardware Wallet Interface), which limits the scope of what we can support.

You can add a wallet, send and receive bitcoin, and confirm your transactions and addresses on the device. You can also use and manage your passphrase directly from your Trezor Safe 3.

Keep in mind, device initialization and firmware updates are not supported and you’re better off using Trezor Suite for that. Finally, as with all our hardware wallet integrations, there’s no support for coinjoins directly from your hardware device with Wasabi.

Coinjoin on Trezor Suite

However, you can coinjoin on Trezor Suite using the Safe 3 and the other two devices. The best part of this feature is that you’ll be using the same coordinator as on Wasabi, the zkSNACKs coordinator based on WabiSabi technology.

To learn more about this integration made possible by our partnership with Trezor, read here. 

How To Use Trezor Safe 3 with Wasabi Wallet

Follow these easy steps:

1. Select ‘Add Wallet’ from the sidebar in Wasabi.
2. In the modal window, click on ‘Connect to hardware wallet‘.

3. Name your new wallet, then click ‘Continue’.

4. Connect your Trezor Safe 3 to your computer and unlock it with the PIN.
   1. If necessary, click on Rescan once your device is ready.

5. Wasabi will recognize your Trezor Safe 3. Confirm by clicking Yes.
6. A success message will confirm the connection. Click on Done.

Your Trezor Safe 3 is now ready for use with Wasabi Wallet!
Download and verify the latest version today.

The post Latest Hardware Wallet Integration: Trezor Safe 3 on Wasabi appeared first on Wasabi Wallet - Blog.

The RPC is used to communicate with a running Wasabi instance. It provides some options and features which are not available (yet) when using the Graphical User Interface. Since Wasabi version 2.0.6, the RPC can be exposed as an onion service, which enables remote control.

Let’s take a look at how to configure the RPC server, its available methods, the features that are currently only available using the RPC. and finally at a usage example.

Configuration

The RPC server is disabled by default. To use the RPC, it has to be enabled in the Config.json file in the Wasabi data folder by setting JsonRpcServerEnabled to true. 

The Remote Procedure Call (RPC) interface allows anonymous and basic authentication access. The default is anonymous access. To enable basic authentication the JsonRpcUser and JsonRpcPassword should be specified in the Config file, and then the right credentials have to be specified at every request.

It is optional (but recommended) to install the jq command line processor and then use | jq at every request to get a structured output.

Available methods

The current latest Wasabi version (v2.0.6) contains 26 RPC methods:

getstatus, createwallet, recoverwallet, listwallets, loadwallet, listcoins, listunspentcoins, getwalletinfo, getnewaddress, send, build, broadcast, speeduptransaction, canceltransaction, gethistory, getfeerates, listkeys, excludefromcoinjoin, startcoinjoin, payincoinjoin, listpaymentsincoinjoin, cancelpaymentincoinjoin, startcoinjoinsweep, stopcoinjoin, buildunsafetransaction, and stop.

Most of these speak for themselves: createwallet creates a new wallet, listwallets list the available wallets etc.

Features currently only available using the Remote Procedure Call

Some methods offer features that are, at the moment of the writing of this article (Wasabi v2.0.6), only available using the RPC interface, like excludefromcoinjoin, payincoinjoin, startcoinjoinsweep and buildunsafetransaction.

excludefromcoinjoin 

Allows to exclude a coin from participating in coinjoin. The coin will never participate in coinjoin until excludefromcoinjoin is set to false.

payincoinjoin 

Allows to pay to a specific bitcoin address in a coinjoin. This saves fees and block space since incoming funds, outgoing payments, and leftover change can all be made private at once.

startcoinjoinsweep 

Allows to sweep (empty) the wallet by sending the coins to the destination wallet in a coinjoin transaction. The destination wallet needs to be a wallet on the same Wasabi client. It works the same as normal coinjoin, except that the outputs are sent to the destination wallet. Note that this is not a proper coinjoin to other wallet implementation, but supposed to be used to empty a wallet.

buildunsafetransaction

Allows to build a transaction with the mining fee being higher than the sent amount, which is otherwise not possible in Wasabi.

listunspentcoins

Although not really a feature, this RPC allows you to see the addresses and derivation path associated with the wallets’ coins, which is not possible to see using the GUI.

Payincoinjoin

One RPC-only feature worth highlighting is the payincoinjoin. Using this RPC method, the user specifies a destination address and the amount, and then the payment will be done in a coinjoin.

In theory, payments in coinjoins be made to any ScriptPubKey, however the zkSNACKs coordinator currently (March 2024) only accepts P2WPKH and P2TR outputs.

payincoinjoin only registers a payment, so if coinjoin is not running or the amount is lower than the wallet balance, the payment is queued.

This feature is new since the 2.0.6 release. The payincoinjoin works, but there are still some optimizations to be made, like to make the coinjoin coin selection aware of payincoinjoin to select coins based on amounts to fulfill the payment. 

Usage Example

The RPC interface can be used with both the daemon as well as the GUI. However using the GUI while also doing RPC calls is not supported and can make Wasabi crash.For wallet specific calls, the wallet name should be specified in the URL.

To simply start using the RPC:

1. Have the RPC configured
2. Open the terminal and launch the Wasabi daemon: wassabeed
3. Open a second terminal window
4. Call the RPC methods (one can simply copy paste the examples listed in the RPC docs:
5. For example: curl -s --data-binary '{"jsonrpc":"2.0","id":"1","method":"getstatus"}' http://127.0.0.1:37128/ | jq

(| jq should be removed, if it is not installed)

getstatus

Wallet specific call: listunspentcoins

Wallet specific call with a parameter:

For demonstration purposes, we did it like this by manually entering it in the terminal, but the RPC also makes it possible to do things in an automated way.

For more information about the RPC: explanation and examples of each method, troubleshooting and how to expose the RPC Server as an onion service, please check out the RPC docs.

The post How to Use Wasabi Wallet’s RPC Interface  appeared first on Wasabi Wallet - Blog.

The way this randomness was implemented does not behave like a fair dice, instead, it gives users artificial luck. Random skips occur more frequently while fees are high, and skipping is less likely when fees are low.

How long your wallet waits when skipping rounds is influenced by the coinjoin strategy you choose. There is a different chance to participate in a coinjoin round depending on whether you select “minimize costs”, “maximize speed”, or “maximize privacy”.

The Participation Calculation

The median fee rate of the previous day, week, and month determines the chance of skipping a coinjoin round. This chart shows what percentage of rounds your client will join under each possible combination of fee conditions for each coinjoin strategy profile.

Since the minimize costs strategy uses “weeks” as the coinjoin time preference, there is zero chance of participating whenever fees are higher than the median of the previous day or week. Whenever fees are at the absolute cheapest levels, clients will never choose to gamble away that opportunity and will join 100% of coinjoin rounds.

An additional privacy benefit from random skips is that it staggers the crowd of remixers. Since some users stall in between coinjoins, it increases the likelihood of coinjoining with more unique users as opposed to coinjoining with the same participants of the previous round again.

The subtle privacy fortifications implemented in the Wasabi v2.0.6 release minimize the UX trade-offs with cost or speed that are associated with coinjoins. If you haven’t tried the newest version, don’t skip the upgrade, let the upgrade do the skipping for you!

The post Smart Randomness: Skipping Coinjoin Rounds Based On Fee Rate appeared first on Wasabi Wallet - Blog.

You might wonder: What are the main performance improvements made in this release?

First of all, the application launch was significantly improved such that users can now benefit from a tighter delay when starting the wallet on their computer. This performance improvement reduces CPU usage and memory consumption by half. Then, the initial transaction processing was reduced considerably because of a complete rewrite of the CoinsRegistry component, which is in charge of tracking your wallet’s balance. 

Want to see how performant the new Wasabi Wallet feels? Download and verify the new version now.

This article will outline the changes that contribute to quicker launch times in the latest Juggernaut release (Version 2.0.6), including the migration of transaction data to a database and optimizations for handling multiple wallets. Then, we delve into the rewrite of the CoinsRegistry component and how it improves initial transaction processing. Finally, we’ll explore additional updates that enhance general usage and overall performance.

Reducing the Software’s Launch Time

Whenever you launch Wasabi Wallet by clicking on the application’s icon, there’s a slight delay between that and the moment the GUI (graphical user interface) appears. During that brief instant, many essential background operations take place. 

Here are a few of the adjustments made in the latest Juggernaut release Version 2.0.6 that minimizes the execution time of these operations.

Transaction Data Migrated to a Database

Previously, transactions were stored in a single plaintext file, which was inefficient for data modifications, requiring complete file rewrites for new transactions. This approach was particularly cumbersome for wallets with thousands of transactions.

In 2.0.6, transaction data (TransactionStore) has been migrated to an SQLite database, considerably reducing disk IO (input/output operations), thereby enhancing the software’s launch time. 

This migration also lowers disk and CPU usage during general use and decreases the memory (ROM) used by Wasabi, especially for larger wallets. Users with HDDs (hard disk drives) will notably benefit from these speed improvements.

Multi Wallet Usage Improvements

Wasabi’s ability to support multiple wallets is very convenient. With the latest release, we’ve optimized the loading of multiple wallets to boost performance. Now, when only using Wallet A, the software refrains from loading irrelevant information from other wallets.

Implementing lazy initialization for scripts in HdPubKey significantly benefits multi-wallet usage by deferring important calculations to reduce launch delays. In some tests, this adjustment cut software launch time from 30 seconds to just 10 seconds.

Improving the Initial Transaction Processing

Wasabi monitors the state of your UTXOs and thus of your wallet’s balance with a key component called the CoinsRegistry. In 2.0.6, this component underwent a full rewrite to enhance initial transaction processing. Whenever your wallet is loading but after it’s done downloading blocks, the update of this component is what takes the most time.

In short, this rewrite mainly transforms data structures into a Dictionary format, enabling faster lookups, of which there can be millions.

Additional Performance Improvements

Another notable performance enhancement in this release is the optimization of the Logger, which now requires slightly less time to log an entry. Finally, some algorithmic complexity reduction improvements were implemented such as improving most used labels, to enhance software’s performance during general use.

Conclusion

By re-engineering key components and optimizing data handling, the development team was able to significantly reduce load times and improve overall performance, resulting in a smoother and faster experience for Wasabi users.

Keep in mind that these are only the performance features of this release. You can find all the changes in the announcement article.

The post Load Time Reduced by an Additional 60% in Version 2.0.6 appeared first on Wasabi Wallet - Blog.

How much privacy should you gain before spending your coins?

Since each coinjoin transaction pays a fee to miners, users have to consider whether the marginal privacy gained from remixing in multiple coinjoins is worth the additional cost. Wasabi’s mission is to provide privacy by default, but users have a limited budget, so a careful balance is necessary.

Coinjoin trilemma concept art – A cost tradeoff is associated with maximizing privacy or speed.

Wasabi users are offered three coinjoin strategies when setting up their wallet: Minimize Costs, Maximize Speed, and Maximize Privacy. The cost and speed strategies will typically complete coinjoining after a single transaction while the privacy strategy will remix multiple times. The exact amount of remixing required before stopping may vary because the outcome of each coinjoin transaction is unique.

Safety for the Hasty

In v2.0.6, Wasabi now considers the abstract quality of privacy for your coinjoin outputs in addition to checking their anonymity score. “Safety coinjoins” are triggered by default to ensure a minimum amount of remixing for users who choose to minimize costs or maximize speed. This feature anticipates how coins might be spent in the future to prevent guesses from being made based on a specific user behaviour. The guessing scenario that safety coinjoins protect against is when a user makes a single deposit, a single coinjoin, and a full withdrawal. Wallets that already have private funds for remixing are already protected, so safety coinjoins only occur when users fund a new wallet.

WabiSabi coinjoins can break the links between your addresses in three different ways:

– Inputs are not linked to other inputs
– Inputs are not linked to outputs
– Outputs are not linked to other outputs

Outputs not being linked to each other can be temporary depending on how those outputs are spent. When outputs from coinjoin transactions are spent together as inputs in a future payment, a definitive link is created between them. However, when coinjoin outputs are spent together as inputs in a future coinjoin, no definitive link is created since coinjoin inputs cannot be linked to other inputs. In order to take advantage of this property, the first deposit made to an empty wallet can only achieve a maximum of 75% privacy progress from its first coinjoin, no matter how high your anonymity score is. Safety coinjoins remix the first set of semi-private outputs that were created from the initial coinjoin round to achieve 100% privacy.

Users sweeping their wallets benefit from the extra safety buffer between the transaction that funds their wallet and the transaction that empties it, preserving the initial privacy gained from splitting into multiple outputs. An observer of a safety coinjoin who is attempting to identify the source of incoming funds based on outgoing amounts is forced to expand their search to include previous coinjoin transactions. Any conclusion drawn by equating similar amounts to each other is broken since private coins exit from a different transaction than the non-private coins entered.

If you haven’t taken the chance to upgrade your privacy yet, download the new 2.0.6 version of Wasabi Wallet and see the safety coinjoin feature in action for your first deposit. 

The post Deeper Privacy with Safety Coinjoins appeared first on Wasabi Wallet - Blog.

Coinjoins are privacy-preserving transactions that contain funds from many users. This operation requires unanimous teamwork: Unless every user signs the transaction, Bitcoin nodes will reject it as invalid, and no privacy progress will be made. This poses a challenge to honest users since there is no cost to an attacker who continuously causes coinjoins to fail, resulting in a denial of service (DoS).

This is where the role of the centralized coinjoin coordinator comes into play. The coordinator acts as a bouncer to exclude known troublemakers, ensuring that honest users are not left waiting indefinitely. ZkSNACKs, which runs the default coordinator for Wasabi Wallet, uses various methods to identify and defeat DoS attacks to improve coinjoin success rates.

First, the economics of Denial of Service attacks are considered. The minimum value allowed to participate in a Wasabi coinjoin is 5000 sats (0.00005000 BTC). When disrupting a coinjoin round, the attack is equally effective whether the missing signature belongs to a low-value input or a high-value input. Due to this threat of an attacker splitting his coins into small pieces, low-value coins are subject to longer bans than high-value coins.

Second, Denial of Service penalty evasion is considered. If a particular address is banned for causing a coinjoin to fail, the attacker can move the coins from the banned address to a fresh address and attempt to register again. To combat this circumvention, bans from previously offending addresses are inherited by the coins they send. This prevents attackers from reusing the same funds for multiple disruptions.

Third, the nature of the offence is considered. There are 3 ways to cause trouble with a coinjoin transaction:

• Register inputs and fail to sign the final transaction
• Double spend a registered input before signing
• Double spend a registered input after signing

Failure to sign may not be intentionally malicious since it can occasionally occur due to limitations of the Tor network’s stability, or because a careless user closes his laptop after the input registration phase. Double spending is prevented by clients and is a clearer indicator of deliberate disruptive activity. The type of offence and the history of previous offences affect how long a coin is banned.

Stability Improvements

When Wasabi 2.0 was first released, Tor was under a network-wide attack that severely degraded its connection reliability. As a result, the coordinator cannot be too strict with bans to prevent Denial of Service since honest users may inadvertently disconnect without signing.

In November 2022, benchmark statistics were measured showing coinjoins would succeed only 10% of the time on the first attempt, and slightly less than 50% on subsequent attempts (known as “blame rounds”). With the v2.0.2.1 release in December, these metrics improved to 15% success on the first attempt.

As a result of months of hard work by the Wasabi and Tor developers, updated statistics from October 2023 show that the overall success rate has more than doubled since the previous year, with over 50% of new rounds and over 80% of blame rounds succeeding. This consistency makes privacy convenient for patience minimalists who quickly tire of the soothing glow of the countdown timer.

Entering the Fee Market

The fee rate of the coinjoin transaction is another variable to account for while waiting for full privacy. The coordinator chooses the mining fee for the coinjoin round before users join, however, fee estimation is not a simple task. On average, a new Bitcoin block is mined every 10 minutes, but there is no way to predict exactly when one will be found or how many new transactions will outbid you until then. 

There are special considerations when choosing the fee rate for coinjoin transactions. Participants often pay several times more in mining fees for a coinjoin transaction compared to a regular payment since they can register multiple inputs and outputs. This increases the marginal advantage for sniping the lowest possible fee rate. In addition, coinjoins are not considered urgent because users are often sending coins to themselves and not to others, so whether or not the transaction is confirmed quickly is not as important because there is no risk that incoming funds will be double spent and lost.

Allowing coinjoin transactions to wait in the mempool also has an unintended privacy benefit. Since unconfirmed coins cannot be registered for new rounds, users who remix their outputs must wait an additional time for their first coinjoin to be mined. By increasing the time period in between consecutive rounds, users are less likely to participate with the same users from their previous round.

Despite these advantages for choosing a low fee, there are also unique reasons for coinjoin transactions that would justify choosing a high fee as a precaution. Users who send a regular payment that gets stuck can easily use Replace By Fee (RBF) to increase its confirmation priority. However, since coinjoins require the cooperation of many users, the first fee is final. There is no way to replicate a higher fee replacement if even a single participant goes offline.

Another reason to prefer a higher fee for coinjoins is because they are disproportionately affected by transaction size limitations in Bitcoin Core’s mempool and block construction logic. Once a chain of transactions spending unconfirmed coins grows too large, nodes will ignore new transactions attempting to build on top of it.

Unfortunately, mining pools have not yet optimized to collect fees from coinjoin transactions. Miners only calculate the single highest-paying descendant transaction package, which may cause them to overlook the confirmation of an extra profitable coinjoin with many spent child outputs.

Patience Preferences

Since it’s impossible to choose a fee that satisfies both the impatient and the thrifty at the same time, Wasabi has a feature called “Coinjoin time preference” to ensure that you don’t get hit with higher than expected mining fees.

If a coinjoin round requires a higher fee than the median of the previous day, week, or month, your client can be configured to skip that round and wait until fees drop or stabilize. This customization gives both spenders and savers flexibility without compromising their preferences or splitting the liquidity pool.

Setting a long coinjoin time preference makes it easy to handle the small coins that accumulate in your wallet as you send and receive transactions. Whenever the best deal on fees becomes available, your wallet will privately consolidate your UTXOs so you can readily spend them when fees increase again.

In conclusion, the combined speed provided by Denial of Service fortification and smart savings from the coinjoin time preference feature has significantly improved Wasabi’s user experience. These advancements and tools have made privacy not only more convenient but also more cost-effective. Coinjoins have never been spicier, try Wasabi Wallet today and join the crowd.

The post Time is Money: DoS (Denial of Service) Fortification and Coinjoin Time Preference appeared first on Wasabi Wallet - Blog.

The question then becomes: How do coinjoin wallets compare on on-chain transaction fees?

Bitcoiners may find different protocols advantageous depending on the amount they are coinjoining, or how long they are willing to wait before spending. For example, if an input you want to coinjoin is of a ten million sats or less, WabiSabi wallets are ideal unless you’re willing to wait days or weeks coinjoining, which in that case Whirlpool would be better due to the free remixing policy. 

In cases where you are willing to provide liquidity and wait for others to coinjoin, you may prefer acting as a Joinmarket maker to passively earn sats. Finally, if you’re coinjoining more than 1 BTC, Joinmarket basically almost always wins in terms of fees. 

It’s also important to remember that this analysis was purely from the fees to be paid point of view, and didn’t take into account how strong each privacy guarantee is for each protocol. To learn more about the benefits and the tradeoffs of each coinjoin protocol and wallet, visit the open-source educational website Coinjoins.org. 

If you want to know how WabiSabi, Whirlpool and Joinmarket fee structures work, read on. We’ll define all the fees of a coinjoin transaction, the way fees are calculated for each protocol and finally, which one is better for many different user profiles. 

What are the Different Fees for Coinjoin Transactions?

To answer what are the different types of fees on a coinjoin transaction, we will explain how coordinator fees work for each protocol, and then how mining fees work for each protocol. 

What are Coinjoin Coordinator Fees?

Protocols like WabiSabi and Whirlpool use a centralized coordinator model to scale privacy, allowing multiple users to cooperate in a transaction without any participant knowing which coins belong to the others. Cryptography and discreet network communication are required in order to ensure that movements of funds are not revealed to the coinjoin coordinator. To learn more about how coinjoin protocols work, read more on Coinjoins.org.

Coordinator fees are what you pay the third-party in exchange for their services. The fee can be static (fixed amount) or dynamic (percentage). 

Coordinator Fees for WabiSabi Coinjoins

For example, in WabiSabi wallets like Wasabi Wallet, BTCPay Server or Trezor Suite, coordinator fees are 0.3% (dynamic) of what you’re mixing (for the zkSNACKs coordinator). You’re only charged on the first transaction so remixing is free of coordinator fees. Also, if someone sends you coinjoined bitcoin, your coordinator fees are waived too. This feature is called Friends don’t pay.

In addition, the Plebs don’t pay feature makes it that coordinator fees are waived for any coinjoin input less than 1,000,000 satoshis (0.01 BTC). This improves accessibility for users with low amounts of bitcoin. 

Coordinator Fees for Whirlpool Coinjoins

On the other hand, on Whirlpool wallets like Samourai, Sparrow, and Bitcoin Keeper, coordinator fees are of a fixed amount, depending on the liquidity pool you choose to be part of. Here’s the breakdown per pool:

• 100,000 satoshis pool: 5,000 sats of coordinator fees
• 1,000,000 satoshis pool: 50,000 sats of coordinator fees.
• 5,000,000 satoshis pool: 175,000 sats of coordinator fees.
• 50,000,000 satoshis pool: 1,750,000 sats of coordinator fees.

You might be wondering what a coinjoin pool is. In short, it’s the coinjoin output denomination amount. The 100,000 satoshis pool will result in coinjoined outputs of that precise size. Here’s a visual example for the 5,000,000 satoshis pool: 

As you can see, every output is of the same value. When you enter a pool, you pay the fixed fee amount. However, you can enter a pool with much more than the pool denomination, to be exact you can enter with up to 70 times the pool denomination, split across 70 outputs (for the 100k sats pool it’s only 25 times). 

Now on to Joinmarket, which doesn’t have coordinator fees but there are coinjoin fees.

Coinjoin Fees on Joinmarket

Joinmarket works differently than other coinjoin protocols because it doesn’t have a centralized individual entity coordinator, but rather two user roles in a P2P (peer-to-peer) environment: makers (who provide liquidity for a fee) and takers (who pay a fee for liquidity and coordinate the transaction). Any user can be a maker or a taker.

In short, instead of paying for coordination, you pay for liquidity. There’s an orderbook with all maker offers and at different price points. Some charge a static fee (fixed amount) but most charge a dynamic fee (a percentage of the liquidity used). 

When you’re a taker, you use the liquidity of many makers in a single transaction, usually 8, which makes 9 participants including you. You pay each maker what they ask for. For example, if there’s 8 makers and each charge a dynamic fee of 0.0001% BTC for the liquidity used, and you use 1 BTC of each, you pay a total of 10,000 sats * 8 = 80,000 sats.

This is the case for each Joinmarket transaction you’re the taker on. If you’re a maker, you enjoy privacy and you get paid for it: the best of both worlds.

How Mining Fees Work on Coinjoin Transactions?

Mining fees are part of every transaction on the bitcoin network, and coinjoins are no exception. It works differently for all three major protocols. Here’s a tool to calculate bitcoin transaction size. 

Mining Fees on WabiSabi Coinjoins

On WabiSabi coinjoin transactions, you only pay the fees associated with the blockspace your inputs and outputs take. For example, if you have a P2WPKH (segwit native) wallet and you have 3 inputs and 5 outputs in a coinjoin transaction, and the current fee is 50 sats/vbyte, you will pay:

Total blockspace: 3 * 68 vbytes + 5 * 31 vbytes = 359 vbytes

Total mining fees: 516.5 vbytes * 50 sats/vbytes = 17,950 sats

You pay exactly what you consume in blockspace, in every coinjoin transaction you participate in. 

Mining Fees on Whirlpool Coinjoins

The mining fee structure of Whirlpool coinjoins is a bit more complicated, but nothing that we can’t explain. Here it goes.

First off, it’s important to understand that before the coinjoin process begins, a premix transaction, also known as Tx0, takes place. The claimed purpose is to split your total input amount into the outputs to coinjoin, the non-private change output that goes into a separate wallet account called BadBank, and the coordinator fee to pay. 

For example, if you have a 1,500,000 sats UTXO for the 1,000,000 sats denomination pool, your premix transaction (Tx0) will have 1 input and three outputs: one output to coinjoin, a 50,000 sats output to pay the coordinator, and a non private change output that goes to the BadBank wallet account.

It’s important to understand that your premix can have many inputs and many outputs to coinjoin (up to 70), but the minimum number of inputs is 1 and outputs is 2 (if there’s no change). 

The first part of the mining fees for Whirlpool coinjoins is the fee you pay for the premix transaction. However, there’s a second part: you have to pay mining fees for the first coinjoin transaction, and not only for you, but for anyone remixing in it. You share that cost with at least one additional user out of 5, but it can be up to 4 out of 5 participants. When you remix and enter further coinjoins, you don’t pay any fees.

How to calculate Whirlpool Tx0 Mining Fees

The formula for the mining fees on Tx0 is as follows (assuming all are P2WPKH UTXOs): 

Total vbytes: Base transaction vbytes + input vbytes * number of inputs + output vbytes * 2 (for change and coordinator fee outputs) + output vbytes * number of coinjoin outputs

Which comes out to: 10.5 + 68 * inputs + 31 * (2 + cjOutputs)

For example, if there are 5 inputs and 10 cjOutputs, the total vbytes will be:

Total vbytes: 10.5 + 68 * 5 + 31 * (2 + 10) = 722.5 vybtes

Total fees (assuming 50 sats/vbyte): 722.5 * 50 = 36,125 sats

How to calculate Whirlpool Coinjoin Mining Fees

Regular Whirlpool coinjoin transactions have 5 inputs and 5 outputs, which comes out to a total of 505.5 vbytes. Considering that 2 new entrants are paying, this splits the duty in two. You’re then responsible for paying 202.75 vbytes, for each one of your 10 coinjoin outputs.

Total fees (assuming 50 sats/vbyte): 202.75 * 50 * 10 = 101,375 sats

This gives you a total of 36,125 + 101,375 = 137,500 sats to pay on mining fees. However, this is a one-time fee, and you will be able to remix for free, for as long as you want.

Now, let’s cover the remaining protocol, Joinmarket.

Mining Fees on Joinmarket Coinjoins

By default, a taker is in charge of paying all the mining fees for a Joinmarket coinjoin transaction. However, there’s a setting for makers to include a mining fee contribution in their offers. In practice, as of the 10th January 2024 at 6:00 AM UTC, there’s not a single offer that includes a mining fee contribution out of 65 offers.

This means that as a taker you will almost certainly pay the entirety of the mining fee required for the Joinmarket coinjoin. This means that for every input, there will be a coinjoin output and a change output. If there are 9 participants, there are at least 9 inputs (there can be more), and at least 18 outputs. It’s also not mandatory that everyone uses the same wallet standard, which means some inputs can cost more than others. Let’s assume every input and output is P2WPKH and that every participant only has 1 input.

Total vbytes: 9 * 68 + 18 * 31 = 1,170 vbytes

Total fees (assuming 50 sats / vbyte): 58,500 sats

In short, the formula to calculate the mining fees paid is (68 * number of inputs + 31 * number of outputs) * mining fee in sats / vbyte.

Now that we’ve broken down how exactly to calculate the fees for every coinjoin protocol, let’s examine which would be better for different profiles.

I have a 990,000 sats (0.099 BTC) UTXO to mix. Which protocol is better for fees?

If you have a million sats or less, here are the coordinator (liquidity for Joinmarket) fees paid for every different coinjoin protocol:

• You won’t pay any coordinator fees with WabiSabi.
• You can only enter the 100,000 sats pool on Whirlpool and you will pay 5,000 sats in coordinator fees.
• FOR TAKERS only: On Joinmarket, it depends on the orderbook: as of the 10th of January 2024, you will pay an average of 0.0007% for 8 makers, which would be a maximum of 56 sats (depending on the mining fee market to know how much you have left in sats). 

Here are the mining fees to pay for every different coinjoin protocol (assuming 50 sats/vbyte);

• WabiSabi: Assuming you have 1 input and 7 outputs (extremely high estimation) are created, you will pay 17,925 sats for the first coinjoin transaction. For each further coinjoin transaction, considering you will have 7 inputs now, you will pay 35,175 in sats.
• Samourai: assuming you have 1 input and 8 coinjoin UTXOs will be created, you will pay a total of 120,650 sats for the Tx0 and the coinjoin mining fee.
• Joinmarket (FOR TAKERS only): assuming you have to pay for a total of 9 inputs, and 18 outputs, you will pay a total of 62,150 sats for each coinjoin transaction. 

In total:

• WabiSabi: 17,925 sats for first, 35,175 sats for further transactions.
• Whirlpool: 125,650 sats in total.
• Joinmarket: 62,182 sats for each transaction.

The conclusion for this user profile is that WabiSabi is better if you’re doing 4 transactions or less, but Whirlpool will become more economical after that. It depends on whether you want to mix fast or slow, and also it’s important to consider that to gain the same level of privacy as with 4 WabiSabi transactions, you will need to make many more on Whirlpool.

Joinmarket is not worth it for this amount unless you’re a maker.

The winner for this user profile: WabiSabi Coinjoins.

I have 10,000,000 sats (0.1 BTC). Which wallet is better?

Now that we’ve broken down the first user profile, we can just jump straight to total fees for the next ones. We keep the same assumptions. 

Total fees for each coinjoin protocol:

• WabiSabi: 30,000 sats (coordinator fee) + 17,925 sats (mining fee) = 47,925 sats for first + 35,175 sats for further transactions.
• Samourai 1M sats pool: 50,000 sats (coordinator fee) + 134850 (total mining fee) = 184,850 sats (5M sats would be possible too but not as economical and with more change)
• Joinmarket (FOR TAKERS only): 317 (liquidity fee) + 62150 (mining fee) = 62467 sats for each transaction

Joinmarket is more competitive but the result remains the same. WabiSabi is better for 3 transactions or less, and Whirlpool for continuous remixing. However, 3 WabiSabi transactions gives you a sufficient level of plausible deniability that is enough to make tracking the transactions of most users super hard.

Winner: WabiSabi (unless you’re a Joinmarket maker)

I have 100,000,000 sats (1 BTC). Which wallet is better?

Total fees for each coinjoin protocol:

• WabiSabi: 300,000 sats (coordinator fee) + 17,925 sats (mining fee) = 317,925 sats for first + 35,175 sats for further transactions.
• Samourai 5M sats pool: 175,000 sats (coordinator fee) + 276850 (total mining fee) = 451,850 (50M sats would be possible too but not as economical and with more change)
• Joinmarket (FOR TAKERS only): 3168 (liquidity fee) + 62150 (mining fee) = 65,318 sats for each transaction

For this category, Joinmarket is the winner under 7 transactions, then Whirlpool is more economical. WabiSabi is better than Whirlpool for 3 transactions or less.

Winner: Joinmarket

I have 1,000,000,000 sats (10 BTC). Which wallet is better?

Total fees for each coinjoin protocol:

• WabiSabi: 3,000,000 sats (coordinator fee) + 17,925 sats (mining fee) = 3,017,925 sats for first + 35,175 sats for further transactions.
• Samourai 50M sats pool: 1,750,000 sats (coordinator fee) + 276850 (total mining fee) = 2,026,850 sats in total
• Joinmarket (FOR TAKERS only): 31680 (liquidity fee) + 62150 (mining fee) = 93,830 sats per transaction

For this category, Joinmarket is the winner under 20 transactions, which means it’s the winner hands down. 

Winner: Joinmarket

Conclusion

We explained how fees work on every major coinjoin protocol such as WabiSabi, Whirlpool and Joinmarket. We then compare them in different contexts ranging from a user that has less than a million sats to one that has a billion sats. Many assumptions are required to be made, but the formulas are shared so you can calculate it in other scenarios where variables such as the number of inputs, the number of outputs and the current mining fee, change. 

It’s also important to remember that this analysis was purely from the fees to be paid point of view, and didn’t consider how strong each privacy guarantee is for each protocol. To learn more about the benefits and the tradeoffs of each coinjoin protocol and wallet, visit the open-source educational website Coinjoins.org. 

The post How Coinjoin Wallets Compare on Fees appeared first on Wasabi Wallet - Blog.

Connecting to the internet through Tor is a core component of a bitcoin privacy wallet. Along with block filters, it’s the answer to bitcoin network privacy.

As expected, Wasabi Wallet comes with Tor bundled in and enabled by default (you can opt out, but it’s not recommended), but how exactly does Wasabi Wallet implement Tor?

Wasabi Wallet makes all of its requests through Tor, but it alternates the connection (circuit) modes so that for super-private things like coordinating a coinjoin, its circuit is updated after each operation. This allows the user to have privacy from both the coordinator, the Bitcoin network and the Tor network.

This article will define what Tor is, how Wasabi Wallet implements Tor exactly, what are the operations that require an immediate circuit update, why the coordinator doesn’t use an onion service anymore, and how Conflux could be a future solution to improve reliability.

First, it’s important to understand that using the Internet without Tor (or alternative protocols) reveals your IP address to the server you’re connecting to. The goal is to protect a user’s IP address from their Internet peers and the public.

How Does Tor (The Onion Network) Work?

Tor is a free and open source software that enables anonymous communication for online activities by encrypting and routing Internet traffic through a network of servers, making it difficult to trace the origin or destination of data.

In other words, Tor is a peer-to-peer network that anyone can join to hide their IP address from the destination server. Here’s a simple illustration of how Tor works:

Tor is used in Wasabi Wallet for all communication purposes by default, i.e. to connect to the bitcoin network to download blocks and broadcast transactions, and to the coinjoin coordinator to receive block filters and the state of the coinjoin rounds when loading the wallet, and most importantly, for all the communication steps of the coinjoin transaction such as input selection, output selection, transaction signing. (Read about how a coinjoin transaction works in detail). 

Now let’s take a closer look at Wasabi Wallet’s Tor implementation. 

How Exactly Does Wasabi Wallet Implement Tor?

First off, we want to make sure that all communication happens through Tor. Each time we communicate we create an HttpClient (software used to send and receive responses from a server) and we set it up with Tor.

In addition, Wasabi enables Tor’s control port to manage and switch connection (circuit) modes. There are three circuit modes:

• For DefaultCircuit, on every session, we set up a default circuit that we will use when we don’t use other modes, usually for operations that are not too sensitive. 
• For SingleCircuitPerLifetime, we create a new circuit just for this HttpClient, which we will reuse throughout the lifetime of the component that created the HttpClient.
• NewCircuitPerRequest is the most private mode. We use it when we want each request to have its own unique circuit, such as during the coinjoin coordination process.

 It’s important to note that Tor circuits are slow and hard to create, which is why we try to avoid creating new ones when it’s not necessary. Here’s an example to understand better circuit mode management.

When a component needs to communicate on the Internet, it requests a new HttpClient configured with the mode it needs. When we use the RoundStateUpdater (to get the state of the coinjoin round), privacy is not critical. This is because every Wasabi client polls this endpoint, whether it’s actively participating in a coinjoin or not. 

Since this query does not reveal client uniqueness, we create the HttpClient for the component with the SingleCircuitPerLifetime mode.

Now what are the operations that require the highest level of privacy with the circuit mode NewCircuitPerRequest?

What are the Operations that Require Tor Circuit Updates (NewCircuitPerRequest) in Wasabi Wallet?

As mentioned above, Tor is used for all communication when enabled, and a Wasabi Wallet client only communicates with Bitcoin Network peers and the coinjoin coordinator server. Let’s look at the operations that require circuit updates, starting with the coinjoin coordinator process.

For the coinjoin communication, it works separately in two parts:

• Inputs Registration + Inputs Confirmation phases: In this case, it makes sense to use one circuit for all requests related to one input, so we use the SingleCircuitPerLifetime mode, and we create a new HttpClient per input.
• Everything else: For the rest of the critical phase, we shouldn’t link any requests with each other. So we can use a single HttpClient, but we have to use the NewCircuitPerRequest mode.

For Bitcoin network communication, we use NBitcoin and its own Tor implementation so it works very differently. To protect privacy additionally on the block download step, we disconnect from a network peer every time we download a block. 

We’ve explained in detail how the Wasabi Wallet client Tor implementation works, now let’s answer a common question regarding the abandoned use of an onion service for the coordinator server.

Why The Wasabi Coordinator Doesn’t Use an Onion Service Anymore

An onion service is a server configured to only receive incoming connections through Tor, providing privacy and censorship resistance to servers by bypassing DNS.

It used to be the case that the coordinator would run an onion service and clients would connect to it. However, this is no longer the case due to reliability issues inherent in onion services. In addition, the coordinator server doesn’t need privacy from the public so there’s not too much incentive. 

For Wasabi’s coinjoin coordination process to work properly, the standard deviation of the request time must be small. Each request has to happen in a few seconds, and this time frame can’t vary much from request to request. Reliability is a major issue for Tor.

However, a solution seems to have arised…

Conflux as a Potential Reliability Solution for Tor

Conflux is a new Tor project that aims to solve Tor’s inherent reliability problems. If you need bandwidth reliability: you use Conflux, and it duplicates your request and sends each one through different circuits. Since reliability failure is a low-probability event, it’s extremely unlikely to happen with two different requests (e.g., 0.1 * 0.1 = 0.01),

Since Wasabi’s use of Tor varies depending on the action, sometimes we would use Conflux and sometimes we wouldn’t. Unfortunately, this isn’t possible with our current implementation. An alternative implementation called Arti would allow us to solve the Conflux management problem.

Conclusion

In this article, we’ve explored how Tor works, how it’s implemented in Wasabi Wallet through the alternative circuit modes depending on the action, which operations require the most private mode, why the coordinator no longer uses an onion service, and how Conflux is a solution to the reliability issues inherent in Tor. 

This article, among other technical content, demonstrates that Wasabi Wallet is the superior bitcoin wallet for network privacy. To learn more about all the benefits of Wasabi Wallet, check out the Coinjoins.org review. 

The post Explaining Wasabi Wallet’s Tor Implementation appeared first on Wasabi Wallet - Blog.

Wasabi 2.0 has redefined the Bitcoin privacy world with the introduction of the WabiSabi coinjoin protocol. This does not require sacrificing any of the rich features offered by the battle-tested 1.0 version, so that’s why we’re excited to reintroduce the Headless Daemon in Wasabi Wallet v2.0.4. This powerful tool offers a lighter, more efficient way to manage your Bitcoin wallet. No more worrying about resource consumption — the daemon’s got you covered.

What is the Headless Daemon?

Normally, you’d interact with Wasabi Wallet through our graphical user interface (GUI). While user-friendly, the GUI can sometimes demand a lot of your computer’s resources. The headless daemon changes all that. With this new feature, you can interact with your wallet via a simple command line interface. Think of it as your wallet but on a diet. It uses fewer resources like CPU, GPU, memory, and bandwidth, allowing you to run Wasabi Wallet unobtrusively in the background.

Why You’ll Love It

• Developer-Friendly: Before making new features live on the GUI, developers can test them out via the RPC interface.
  
• Always Ready: If you keep it running all the time, there’s no need to worry about synchronizing your wallet every time you wish to use it.
  
• Easy Configuration: No need to navigate through config files. You can override settings with a simple command.
  
• No Compromises: Enjoy all the features you love without any tradeoffs when switching from the GUI to the daemon.
  

How to Run the Headless Daemon

Installed Package

Linux Users

wassabeed –wallet=WalletName –jsonrpcserverenabled=true

macOS Users

cd /Applications/Wasabi\ Wallet.app/Contents/MacOs

./wassabeed –wallet=WalletName –jsonrpcserverenabled=true

Windows Users

cd C:\Program Files\WasabiWallet

wassabeed –wallet=WalletName –jsonrpcserverenabled=true

Building from Source

If you prefer to build from source, you can navigate to the WalletWasabi.Daemon directory and run:

$ dotnet run –wallet=WalletName –jsonrpcserverenabled=true

Examples to Get You Started

1. Connect to Testnet

$ wassabeed –network=testnet

2. Run on Testnet with Additional Configurations

$ wassabeed –usetor=false –datadir=”$HOME/temp/wasabi-1″ –network=testnet –jsonrpcserverenabled=true –blockonly=true

3. Open Multiple Wallets

$ wassabeed –wallet=AliceWallet –wallet=BobWallet

4. Check Daemon Version

$ wassabeed –version

Wasabi Daemon 2.0.4

Wrapping Up

With the headless daemon, power users can easily integrate Wasabi’s unmatchable privacy into their project workflow. Get ready to experience a more streamlined, resource-friendly way of managing your Bitcoin. Upgrade to Wasabi version 2.0.4 today and give the headless daemon a spin!

The post Unpacking Wasabi Wallet’s Power Feature: The Headless Daemon appeared first on Wasabi Wallet - Blog.