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

You are right you could argue that the maker or the taker switch their roll between coinjoins but joinmarket and whrilpool still would give a false sense of a higher anonset then it leads to believe. So it comes off as the makers being almost pointless and making the transaction fees not worth the effort. IMO I think wabisabi is a much better coinjoin system since all inputs are takers with unpredictable output spending. Wabisabi gets a bad rep for blocking certain UTXO's but I think this is a good thing because coinjoining with sanctioned UTXO's will label all UTXO's in the coinjoin as sanctioned.

When you look at a single JoinMarket coinjoin, you can often (but not always) determine common input ownership for the participants and track their change. However, this isn't a limitation that ever requires you to compromise your privacy because you can use the taker role to construct a coinjoin where you have only one input and one (equal sized) output.

Here's an example of a JoinMarket sweep transaction: https://mempool.space/tx/9c6479472e1f3b5861c86bc904d11814e715a84c21aa8d0dd0861e635555451f

You can tell this is a sweep instead of an outgoing payment because there are 9 inputs, 9 equal sized outputs, and 8 change outputs that can be easily connected to maker inputs. The taker's input was from bc1q2pcrqv8jshjalxdan9hdm6qsh0njtm7jxydct9, but there is no trace of his output since it could be any of the 9 values for 0.03846033 BTC.


Yes, common input ownership and toxic change are the same problems inherent to Whirlpool coinjoins as well. The main advantage JoinMarket has to defeat this problem is ability to coinjoin arbitrary amounts, so your toxic coins never have to touch each other. Whirlpool is limited to coinjoining fixed amounts (0.5, 0.05, 0.01 and 0.001), so every transaction you send or receive will require you to forfeit up to 100k sats in unmixable change in order to keep full privacy.

The second advantage JoinMarket has over Whirlpool is that Whirlpool cripples the privacy of users by requiring a premix "tx0" transaction. The premix conclusively reveals all the consolidated inputs are owned by the same person and links it with toxic change that can be tracked in future transactions.

JoinMarket mitigates this privacy leak by skipping the premix transaction and consolidating inputs directly in the coinjoin transaction. Here's an example of a 5 person JoinMarket coinjoin that consolidates 297 inputs: https://mempool.space/tx/63b28f5e17e03fef27795e1ea7fbf821e2d5f072098ffcef3d27b8b2d23ca719

This makes it difficult to determine which inputs belonged to the participant that created the 33677 change output and which inputs belonged to the participant that created the 44384 sat change output.


If 5 out of the 6 equal sized outputs created in the coinjoin end up remixing as makers in the future while the remaining equal sized output is spent in a unique way, the first guess someone would make is that the output that didn't remix was created by the taker. But, this is still a guess and not a 100% guarantee since the taker could have switched roles to become a maker, or a maker could have decided to stop remixing and spend their coins. So, you could have scenarios where all 6 of these outputs remix, or all 6 of these outputs are spent, or any combination in between.

I thought joinmarkets were still pretty easy to unmix. If theres only 1 taker and for example 5 makers in a joinmarket coinjoin it should be pretty easy to unmix them if you watch to see which output get used as inputs for more coinjoins then they are makers and if you can determine which outputs were makers then you can determine which output is the taker by process of elimination.

This is the same problem with samurai wallets whirlpool right?

Question for experienced JoinMarket users: How frequently do you participate in a remix as a maker?

LaurentMT confirms that Whirlpool's incentive model was designed to provide the least amount of anonymity possible: https://twitter.com/LaurentMT/status/1783589807668535563

Some Whirlpool users were rugpulled because they paid coordinator fees in a separate transaction from their coinjoin: https://mempool.space/address/bc1q6dxnvx3wm40e4rtmye6fwy9zmwnqchnz04pzaa

Mempool.space seems to have applied the "Coinjoin" tag to this Whirlpool tx0 transaction as well: https://mempool.space/tx/97a6b985f48c2faf4a3cb7c1e4b5a0ac230fd59aac33723101de9dd144bd735e

I wrote a blog describing how WabiSabi clients can avert future consolidation mistakes by preemptively remixing under certain scenarios: https://blog.wasabiwallet.io/exploring-secure-coinjoin-protocols/

This issue explains the assumptions a lazy attacker would make from observing spent coinjoin outputs and how to avoid imitating the known weakness of ZeroLink consolidations: https://github.com/zkSNACKs/WalletWasabi/issues/10565

Coinjoining takes time and block space, and since both are limited resources, the debate is consequential. No one wants to waste either.

Is everyone still fighting over which CoinJoin is the best in Bitcoin Land?

¯\_(ツ)_/¯

I believe it's not only about which CoinJoin tool you're using, it's also about HOW you use the tool. Simply, it's not enough to merely CoinJoin. The user has to do a lot more after the CoinJoin.


Both sides of the debate in the topic are probably right and wrong at the same time depending on the context.

I gave you some merit because at least you are trying smh

Another coinjoin detecting tool is mempool.space, it highlights coinjoins pending inclusion in a block:

Thanks for the resource.  Yes, this paper explains in more detail what I couldn't seem to get DaveF to understand:


This one, unfortunately, is not a good resource- It's a Craig Wright style propaganda piece that tries to steal credit from Satoshi and give it to a woman instead:


Satoshi's identification of this tracking method wasn't a "hint" and it wasn't "inadvertently", it's quite literally titled "Privacy" in the whitepaper. The author is simply trying to deceive readers into thinking this woman made a profound discovery when all she did was read the whitepaper.

Good reading on the matter "Heuristics for Detecting CoinJoin Transactions on the Bitcoin Blockchain".

They analyzed various implementations of Coinjoin including  JoinMarket,  Whirlpool and Wasabi (from 1.0 to 2.0), applied different heuristics to them and got some success.

Also, worth to read is the following -   "How a 27-year-old busted the myth of Bitcoin’s anonymity". - which shows that all depends on appropriate and adequate obstinacy of investigators,

I guess I didn't catch your point, can you refer to your quote and indicate what is lacking a response?  I'm still waiting for you to respond to my points above:




So the Whirlpool coordinator's output is easily identified. That's unfortunate...

Let's compare this privacy loss in Whirlpool to a WabiSabi coinjoin where the coordinator fee adds to the anonymity set: Which output is the coordinator fee???  https://mempool.space/tx/74254011886f8bcbc19269030a07d3e63cee242492f7a32818152e51995e6d31


You simply haven't looked into how coinjoins work at all since you are accusing WabiSabi of creating negative dust when it's clearly Whirlpool that's creating negative dust, and claim WabiSabi's Boltzmann score is worse despite not having calculated the score at all.  Numbers don't lie, but you do.

Avoiding my point, as usual.

Completely irrelevant and debunked already: https://bitcointalksearch.org/topic/m.63120005.

Because it makes a splash. Whirlpool has maximized the entropy, whereas in Wasabi there is address reuse, possible input and output collaborators, merges-- all of which would reduce the overall entropy.

---

At this point, I'm putting you back on ignore, because we're going on cycles, and you simply want to just say the last word. There is nothing constructive that I can make out of you.

I don't know what you mean by "A user is not warned from reusing an address", Satoshi very clearly warned that a new address should be used for each transaction:


If you never calculated the Boltzmann score, then why did you claim the Boltzmann score for a WabiSabi coinjoin is "worse"?

So, to sum up. A user is not warned from reusing an address in both inputs and outputs of their coinjoin, despite being a complete waste of both money and privacy, because the coordinator does not want to be "malicious" and prevent potentially malicious activity. Makes sense.

I don't work at Samourai, so this is a disclaimer that I have not studied Boltzmann analysis to feel competence and confidence, but it is an attempt to resist against merged input heuristic and to identification of linking between coinjoin inputs and outputs; attacks made by blockchain analysis that you're proudly funding, and which can de-anonymize Wasabi coinjoins as they say. Description of these metrics can be found in Samourai's repo.

I didn't repeat myself, this was the first time I've asked you why you would choose to create toxic change from coinjoining that causes privacy loss instead of choosing not to create toxic change from coinjoining to keep your privacy.


If you are using a second coinjoin to solve the privacy flaw of the initial Whirlpool coinjoin, then why not just perform a single coinjoin that doesn't have the initial privacy flaw so you can cut through these two transactions?


If this request is ignored, then the coordinator would have to propose a 5 input 4 output transaction to the participants that spends the value from the ignored output on the mining fee instead, or replace the missing output with their own address.


That's what I'm asking - I want to see this information that reduces the uncertainty for myself.  Using this coinjoin transaction, what information is revealed from these input and output merges that reduces the uncertainty?


So you're saying that WabiSabi is too powerful for the Boltzmann analysis technique to handle  

Repeated soundbite. I ignore.

You do not consolidate your private coins in the the coinjoin, but after it, using a mix partner.

Yes, it does. Alice can normally register her bc1qalice input, and the coordinator will refuse to create a bc1qalice output. The attacker can be ignored.

I said:

That does not mean I can de-anonymize the outputs with certainty, as I can with a 20 inputs 1 output transaction. I can only say for sure that there is information which can reduce the uncertainty, and which does not appear in Whirlpool. See yourself: https://kycp.org/#/323df21f0b0756f98336437aa3d2fb87e02b59f1946b714a7b09df04d429dec2.

Probably because Samourai's implementation of Boltzmann score's computation is not optimized; I just cloned their repo, entered a Wasabi transaction, and it's still loading. WabiSabis are very big in size, not even oxt.me has worked it out (TX ENTROPY is N/A in summary). Maybe I optimize it once I find the time.