Wasabi Wallet - Total Privacy For Bitcoin

[Pmalek]

TRM Labs claims to have demixed certain Wasabi and mixer transactions in connection to the stolen crypto from the LastPass hack in 2022. Wallets allegedly drained in 2024 and 2025 were linked by TRM Labs on-chain back to their original clusters. They further claim that they were able to follow the stolen crypto to Russian fiat on/off-ramps even after they went through Wasabi and mixers. It's believed that $28 million was converted to bitcoin and coinjoined through Wasabi in late 2024 and early 2025.

TRM analysts allegedly use certain "demixing techniques" to match deposit to withdrawal clusters. By considering values and timings of on-chain movements, they tie pre-mix bitcoins to post-mix bitcoin and conclude that the same operator controls certain deposits and withdrawals from Wasabi.

Besides the claims by TRM, there is no actual evidence or examples showing that they connected pre-mixed bitcoin to post-mix bitcoin and inputs to outputs. At least not in this blog post.


Source: https://www.trmlabs.com/resources/blog/trm-traces-stolen-crypto-from-2022-lastpass-breach-on-chain-indicators-suggest-russian-cybercriminal-involvement

[NotATether]

Besides the claims by TRM, there is no actual evidence or examples showing that they connected pre-mixed bitcoin to post-mix bitcoin and inputs to outputs. At least not in this blog post.

Without actual evidence, their claims must be taken with a grain of salt, because WabiSabi coinjoins can be of variable sizes AFAIK depending on the server configuration.

[FinneysTrueVision]

TRM analysts allegedly use certain "demixing techniques" to match deposit to withdrawal clusters. By considering values and timings of on-chain movements, they tie pre-mix bitcoins to post-mix bitcoin and conclude that the same operator controls certain deposits and withdrawals from Wasabi.

Demixing is a somewhat misleading term because they have not broken the obfuscation algorithm to know with 100% certainty which outputs came from which specific inputs. Using Wasabi in and of itself isn’t enough to deanonymize a user. What they can analyze are behavior patterns. If you are trying to launder millions of dollars, you are still going to stick out like a sore thumb if you are sending large amounts of coinjoined BTC in a systematic, identifiable manner to 1 or 2 centralized destinations. With enough educated guesswork, you can eventually piece together enough information, with clues left by the hackers, to say ‘this is the most plausible culprit’.

[lontivero]

By considering values and timings of on-chain movements, they tie pre-mix bitcoins to post-mix bitcoin and conclude that the same operator controls certain deposits and withdrawals from Wasabi.

What does "By considering values and timings of on-chain movements" mean? Imagine you're monitoring Wasabi coinjoin liquidity and notice that a substantial amount of money enters the system, significantly increasing available liquidity. For example, let's say 600 BTC flows in. You then observe that total system liquidity stabilizes at this higher level—indicating the entity that deposited is still actively coinjoining. At this point, you can no longer track the funds, but you know the entity remains in the mixing process.

Then, you notice liquidity drops sharply—say, by 300 BTC. You decide to trace the outgoing funds and discover either a large consolidation of tens or hundreds of bitcoins, or multiple deposits flowing to the same exchange. Shortly after, liquidity drops again. Following the exiting funds once more, you find additional consolidations or more deposits to that same exchange.

Here's the critical question: what are the odds that 600 BTC entered the system and 600 BTC exited—only to end up at the exact same exchange?




This is why a whale can never hide among small fishes. This is why big consolidating lots of coins is a bad idea, especially for whales and this is why using Wasabi as a mixer is a bad idea.

[Pmalek]

What does "By considering values and timings of on-chain movements" mean?
<Snip>

TRM Labs' analysis is guesswork based on observable patterns. They couldn't identify the individuals doing the coinjoining. At least, there is no proof of it in the shared article. The only thing that the analysis showed was that stolen funds (around $28 million BTC) were sent to Wasabi for coinjoining and then similar numbers around the same time were observed going to Russian fiat on/off ramps. Some of them sanctioned before or maybe because of the connection to the stolen crypto. And yes, the inputs and outputs stand out because of the huge number of money involved.

[JollyGood]

This is something some people/teams find as a challenge. If they can find the root of an mix or coinjoin they will get the plaudits and publicity that goes along with it. Others might want to remain anonymous but want it known if mixers and/or coinjoins can be traced back to the origin therefore want to discover if it really can be achieved.

I am not stating it is impossible, however credibility is essential. Any individual, group or organisation making claims really should provide substantial evidence before announcing anything otherwise they will never be taken seriously. Until (or unless) they provide evidence, their claim means nothing.

TRM Labs claims to have demixed certain Wasabi and mixer transactions in connection to the stolen crypto from the LastPass hack in 2022. Wallets allegedly drained in 2024 and 2025 were linked by TRM Labs on-chain back to their original clusters. They further claim that they were able to follow the stolen crypto to Russian fiat on/off-ramps even after they went through Wasabi and mixers. It's believed that $28 million was converted to bitcoin and coinjoined through Wasabi in late 2024 and early 2025.

TRM analysts allegedly use certain "demixing techniques" to match deposit to withdrawal clusters. By considering values and timings of on-chain movements, they tie pre-mix bitcoins to post-mix bitcoin and conclude that the same operator controls certain deposits and withdrawals from Wasabi.

Besides the claims by TRM, there is no actual evidence or examples showing that they connected pre-mixed bitcoin to post-mix bitcoin and inputs to outputs. At least not in this blog post.


Source: https://www.trmlabs.com/resources/blog/trm-traces-stolen-crypto-from-2022-lastpass-breach-on-chain-indicators-suggest-russian-cybercriminal-involvement

[Coinjoiner21]

Coinjoiner now coordinates coinjoins that pay less than 1 sat/vb!

Recent example: https://mempool.space/tx/1ecf3b63dd21010386e2154551a2dfbc9442c2eca5a1ad10fca3b98996288f50.  We use Mempool.Space's accurate fee rate estimation tool to select the fee. 

Connect to your Wasabi Wallet: URI "https://api.coinjoiner.com", using min input count 8.

[Kruw]

I plan to record some more video guides to help new users understand Wasabi better:

- How to download and use the WasabiNostr app to find coordinators
- How to verify the PGP signature of your download
- How to pay someone directly in a coinjoin transaction using the RPC
- How to run a coordinator
- How to create SLIP39 recovery seeds

[Coinjoiner21]

- How to pay someone directly in a coinjoin transaction using the RPC

How about you hold that one, and I try to pull a request? 

https://i.ibb.co/R4Ct0VRz/Screenshot-from-2026-01-25-00-34-39.png

https://i.ibb.co/jvnr6kHf/Screenshot-from-2026-01-25-00-36-12.png

[Kruw]

- How to pay someone directly in a coinjoin transaction using the RPC

How about you hold that one, and I try to pull a request? 

  that looks cool, good work.

[Coinjoiner21]

I have created a pull request: https://github.com/WalletWasabi/WalletWasabi/pull/14264

You can try to use the feature by cloning my fork of Wasabi:

Code:

git clone https://github.com/Coinjoiner21/WalletWasabi.git
cd WalletWasabi
git fetch
git checkout feature/coinjoin-payments

And then build:

Code:

cd WalletWasabi.Fluent.Desktop
dotnet build

I have successfully tested paying with coinjoin in mainnet and testnet4.

Commit: https://github.com/Coinjoiner21/WalletWasabi/commit/e70e4fa38466a329592dacd0db74f5689a3bd001

[magician0_0]

I plan to record some more video guides to help new users understand Wasabi better:

- How to download and use the WasabiNostr app to find coordinators
- How to verify the PGP signature of your download
- How to pay someone directly in a coinjoin transaction using the RPC
- How to run a coordinator
- How to create SLIP39 recovery seeds

I have done research on wallets that preserve privacy and Wasabi is the one I get to read about most of the time. I am not very good in these challenging setups. But I have acquired bitcoin and I would like to preserve privacy. What is the setup that does this job for me while requiring the least amount of effort? Can I download and go or what are actions that should in any case be taken before using the wallet?

Ty

[Kruw]

I have done research on wallets that preserve privacy and Wasabi is the one I get to read about most of the time. I am not very good in these challenging setups. But I have acquired bitcoin and I would like to preserve privacy. What is the setup that does this job for me while requiring the least amount of effort? Can I download and go or what are actions that should in any case be taken before using the wallet?

Ty

Here's a video guide that walks you through each step, it's really easy: https://www.youtube.com/watch?v=tKwGkR3EcJY

Other than that, you can check the documentation or post here with any questions.

[Coinjoiner21]

The pull request was merged into Wasabi Wallet.  Thanks to Kruw, lontivero and MarnixCroes for contributing. 

What else would you like to see being added in Wasabi?

[Coinjoiner21]

Another pull request that allows sending sub-1 sat/vB transactions has been merged: https://github.com/WalletWasabi/WalletWasabi/pull/14359.  It will hopefully be available in the next release, but you can use it now if you clone Wasabi from Github.

And another pull request is on its way... "Add Pay-to-Many (batch payment) support in Send flow"

[Coinjoiner21]

For those who agree with my suggestion, a positive reply would be appreciated: https://bitcointalk.org/index.php?topic=5576456.msg66475128#msg66475128

[Coinjoiner21]

@Kruw and @lontivero, I'm thinking of an addition to Wasabi that I want to discuss with you.

It is currently possible to pay to a silent address, but not to receive funds at one.  Wasabi does not support generating silent addresses or monitoring silent payments.  Is this feature planned for future implementation, or is there a decision not to support it?

The reason why one can be skeptic on this feature is that silent payment monitoring breaks the compact block filters model.  I have been reading that BIP352 could provide the functionality of the monitoring in a lightweight way.  It would increase the sync bandwidth and the codebase complexity though.  

I was thinking that it could be a nice optional feature especially for node runners.

[lontivero]

Wasabi has been in survival mode for more than a year now, that means that all the development was focus on making the wallet work without a central server. We are very close to achieve that and then we will be more willing to work on other things. Receiving Silent Payments (and spending the received coins) was a planned time ago, in fact all the crypto was implemented since day one, but the problem was that it requires an indexer, a component that I want to remove asap. You can see the PR https://github.com/WalletWasabi/WalletWasabi/pull/13606

I don't want to develop or host an indexer either but there are people developing services that provides you the tweaks so, I think that for those who are willing to accept silent payments, they should chose the indexer and connect to it, that would be ok (always over Tor),

Something that would be even better is if bitcoin core/knots would provide the tweaks via rpc calls, if one days that happens I would implement the receiving feature immediately.

Btw. I think this kind of conversations would work better in the TG channel.

[Kruw]

1. I once long ago already asked a question, or wanted to ask ... Are there considered variants of release of versions under ARM ? Or the software uses instruction sets of x86/AMD64 architecture ?

There's been lots of progress on arm64 support for Linux, check it out - https://github.com/WalletWasabi/WalletWasabi/pull/14407

[NotATether]

Wasabi has been in survival mode for more than a year now, that means that all the development was focus on making the wallet work without a central server. We are very close to achieve that and then we will be more willing to work on other things. Receiving Silent Payments (and spending the received coins) was a planned time ago, in fact all the crypto was implemented since day one, but the problem was that it requires an indexer, a component that I want to remove asap. You can see the PR https://github.com/WalletWasabi/WalletWasabi/pull/13606

I don't want to develop or host an indexer either but there are people developing services that provides you the tweaks so, I think that for those who are willing to accept silent payments, they should chose the indexer and connect to it, that would be ok (always over Tor),

Something that would be even better is if bitcoin core/knots would provide the tweaks via rpc calls, if one days that happens I would implement the receiving feature immediately.

Btw. I think this kind of conversations would work better in the TG channel.

Why not just make every client have an encrypted indexer? And then everyone fetches new entries of the index from other nodes, and they can only decrypt the addresses for which they have a keypair for?

For the address encryption, since there will be so many silent payment addresses created, just use chacha20-poly1305. It's faster on x86 without hardware acceleration where everybody will be using Wasabi on anyway. Then use HKDF with any secure curve so that you have a master key deriving a unique key whenever a new silent payment is created.