Topic: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths! (Read 2341 times)

For the ideal circumstances of an individual who uses every thing properly, it is a good idea to follow your Bitcoin through multiple layers of Privacy before the end destination.  However, I think most of us never do things perfectly considering we are humans after all and it leads to a few problems.

I believe the first Privacy layer has to be the second strongest, but the final layer the strongest if top Privacy is desired.  Sending Bitcoin through multiple layers of Privacy is overkill for many and I some times agree with that.  There is no point in being so desperate if after bouncing Bitcoin from Coin Joins to Lightning, Monero and other methods the final destination is Binance.  That is just burning Money down the road on Fees and all for zero Privacy effects.

Then there are a lot of people who think a Coin Join will do wonders but they are using SPV enabled Electrum on their Windows office laptop and they will happily 'Anonymously' purchase stuff online with the same Bitcoin, filling up forms of personal information before placing orders.

But then there are also people who make subtle mistakes they will only later on find out about, when it is too late and their Privacy is gone anyway.  From my personal experience, what I suggest is that while it is a good idea to bounce Bitcoins through various methods of improving its Privacy, it is an excellent idea to consider those Bitcoins compromised EVERY time, even if they were bounced through 100 Coin Joins.  These Bitcoins should be used normally but Privately.  Learn from mistakes, move on and do a better job next time.  At the end of the day, Bitcoin Privacy involves a really lengthy learning curve and even the best may mess up.

I'll be a broken record, but for those people who haven't heard it, hear it now. - That's probably why it might be good OPSEC to add another layer of untraceability after a CoinJoin by sending a transaction to yourself through the Lightning Network using those CoinJoined outputs.

  ¯\_(ツ)_/¯

Here's an example that seems to indicate a trace vector for a whale in a round with insufficient liquidity: https://mempool.space/tx/804caad877c077c2f368b643eb9b5dbcf3f8845a977afc2ff3a3f9e0db02f5c3

At face value, you would probably assume that the 28.72536879 BTC output must belong to either the 23.24522934 BTC input or the 21.47483648 BTC input. However, it's likely that both inputs belong to the same wallet since there is only one change output, not two. This is an extremely rare edge case, and it can be mitigated by users freezing coins on the client side, coordinators issuing more vbyte credentials, or limiting the upper bound for input registration values so that amounts in the coinjoin are more uniform. Still, it's possible these inputs do not belong to the same wallet, so it's not 100% conclusive.

No, I don't completely understand the issue and I am doing more research.

I see that nothingmuch has replied to your tweets. I doubt you completely understand the issue and I would suggest you to do more research.

The discloser and publisher did not respond to my comment, which I would expect if the accusations were made in good faith: https://x.com/Kruwed/status/1870559181486645687

Bitcoin Optech: https://bitcoinops.org/en/newsletters/2024/12/13/#deanonymization-vulnerability-affecting-wasabi-and-related-software
Mailing list: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ

I think users should not trust your coordinator if you are still being dishonest and misleading about the vulnerabilities.

This describes a client level bug, not a protocol level vulnerability.

Wabisabi coordinators can link inputs with outputs and multiple inputs belonging to same user.

Vulnerability details: https://github.com/GingerPrivacy/GingerWallet/discussions/116

Related tweet thread: https://xcancel.com/not_nothingmuch/status/1866138694920344055

I just experienced the same sort of decomposition and figured out why this would occur:


If you register only one input, you have a limited amount of vsize credentials available for creating outputs. So even if you could efficiently decompose without creating change, you aren't authorized to buy that much block space in that round, so there's a decent likelihood that a change output is created when you coinjoin from a brand new wallet.

Although the absolute forfeit maximum is 10,000 sats, the decomposer attempts to waste as little as possible (the simulations from the mailing list post measured <500 sats per round, with performance scaling as you add more participants). You can check the leftover sats forfeited from each round on https://liquisabi.com and compare it to the total mining fees paid for that round, it's normally only 10%-20% of the total cost (depending on the mining fee rate of that round).

The text from the image justifies the "maximum mining fee" displayed in the user's client, but it does not explain that even with an acceptable mining fee (e.g., 6.03 for me), the user might still be in the surprising position to pay more than he thought he would. (Because, for example, the decomposer treats a significant amount as dust.) At least that's what I understand.

I see. I'll try that the next time.

Yes - https://github.com/WalletWasabi/WasabiDoc/pull/1859


Yes, the feature only allows you to move coins from one of your wallets to another wallet you have loaded on the same client.

If you want to pay specific amounts to selected addresses, you can do so through Wasabi's RPC or with BTCPay's coinjoin plugin (via the 'schedule transaction' workflow).

This is the uncertainty I'm talking about. The user does not know beforehand how much money will be forfeited because the decomposer treats the remainder as dust. Is there a page that explains how this works behind the scenes, ensuring users aren't surprised by paying significantly more than expected?

I had found that, but I assume that allows me to send only to Wasabi wallets, correct? I cannot send the joined coins to Sparrow or to a bunch of addresses I select?

Yep, assuming your calculations are correct, that means the decomposer forfeited 432 sats worth of dust that couldn't be split into equal sized outputs.


It's under the 'Coinjoin' tab within 'Wallet settings'. There's a bunch of nested menus that are annoying to navigate, but the devs have bigger tasks to work on than fixing navigation  

I tried to verify those numbers by calculating the fee I paid for my coinjoin. In this coinjoin, I used a segwit input and created two taproot outputs. With 6.03 sat/vb, I should have paid 6.03 * 69 + 2 * 6.03 * 43 = 934.65 sat, but I paid 1366.

Where's this "Coinjoin to another wallet" option? I cannot find it in settings or in Wallet Settings.

https://github.com/WalletWasabi/WalletWasabi/blob/master/WalletWasabi/Helpers/Constants.cs#L27

It's ~1% bigger in vsize. Spending a P2WPKH coin costs 69 vbytes, creating a P2WPKH coin costs 31 vbytes (100 total). Spending a P2TR coin costs 58 vbytes, creating a P2TR coin costs 43 vbytes (101 total). There's apparently also an extra .5 vbytes somewhere that I don't know how to account for.


I'm sure there's a way to manually disable a specific script type from the client side. After all, when you use the 'Coinjoin to another wallet' to sweep your hot wallet into your hardware wallet, it will only use the supported script type of your HWW.

Okay, but that makes it less block space efficient. I do not have the exact numbers, however, but if I'm not mistaken the taproot would be 10% bigger in size.

Wouldn't it make more sense for the clients to select which script types they rather use? (In addition to the coordinators enforcing their own policy.)

BTCPay clients only support a single script type, and Trezor clients only support Taproot. In order to provide sufficient anonymity for these other clients, Wasabi clients choose both script types randomly.

Coordinators can restrict the allowed script types in their config if they want to.


The devs are aware. I suppose I could open an issue for it, but it seems like a pretty harmless bug.


I'm not a programmer, so I'm unable to audit the code myself.

Now I have several questions.

• Why should there be a ratio? Why not just all segwit or all taproot?
• Is it a bug you and I are just aware of, or is there some Wasabi developer aware as well?
• Have you investigated the source code yourself and not found what goes wrong?