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

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?

The client is only able to calculate all of the potential output decompositions after the end of the input registration phase, so it's not possible to do this manually with precision. But yes, the "slot machine" aspect can be frustrating if overpaying fees bothers you.

BTCPay Server's coinjoin plugin allows power users to choose a minimum denomination amount, exclude certain denominations, etc so they can avoid surprises.


You're not going to like the answer, lol. It's a bug: The ratio should be ~50/50

If you find the source of the bug in the code and open an issue accurately describing it, I'll award a 50k sat bounty. If you open a PR that fixes it and gets merged, I'll award a 100k sat bounty.


Taproot is barely less efficient than segwitv0 when measured in vbytes, but it's much more efficient in terms of actual bytes. If the witness discount multiplier were slightly lower than 4, then Taproot would win out in both categories.

I see. You just don't assign them a metric, because that'd be against the notion of being as rigorous as possible with defining the anonymity score.

Shouldn't the client give the user control over how many times it can divide an input? For example, one might not prefer to divide their 0.01 BTC into 5 worth of 200,000 sat each, because it's more expensive. And I did experience it as well, if you want some feedback; I felt as if I wouldn't know beforehand how much money would be spent on the transaction fee.

---

Is there any particular reason why taproot addresses are preferred over segwit? Isn't it less block space efficient?

Here's a couple of anecdotal transactions showing some nuances of anonymity score.

In this smaller coinjoin transaction, there were (at least) 4 different standard denominations that received anonymity score 1.

bc1pn5g6wmqs2prld00g5sp4l6837s6xt0lg27smt0zrgdlca9qdkycs3ernz8 - ‎0.00020000 BTC    
bc1pjvng7exw3d6ttu438249yasrpuprfwgc8mz6a55thxmat9hm08csgv6s0v - 0.00016384 BTC    
bc1phwkkwk6n2l75xg64wp3nsevkawzhgc9kpfs3rg99a5cghqw7mssq527s9v - 0.00013122 BTC    

These small standard outputs aren't "change", but they are treated like change by the client due to a lack of other matches. Despite being assigned a weak score, these outputs are completely impossible to attribute to any specific input in practice.

bc1qm2kmhgde2fey05ef2dhj3s35a9ayduke2uhgsu 2.68435456 BTC

Although the largest output appears like a whale created a change output, this amount is actually a standard denomination. The user who received this output was unlucky that the other whales in the transaction randomly allocated their liquidity to 2.00000000 BTC sized outputs instead. Even though this output received anon score 1, it's still difficult to determine which input is responsible for creating this coin (although it's far easier to guess who created an output worth 2.68435456 BTC compared to an output worth 20000, 16384, or 13122 sats).

___________________

Here's another rare anon score outcome I personally experienced -



I received 5 same sized outputs from a single round, so the client divided the anon score gain of each of those outputs by 5. While this seems like "waste" from the calculator's perspective, the real world effective privacy gains of allowing this sort of amount skew is massive since analysts are forced to consider many subsets of possible compositions and decompositions.

It often requires creating 5 to 6 outputs to efficiently decompose into matching values with other users. Creating less than 3 outputs is a pretty rare outcome.


Clients automatically filter some potential denominations depending on the inputs present in the round. Here are all of the possible standard values: https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-are-the-equal-denominations-created-in-a-coinjoin-round


Clients automatically forfeit small dust amounts that can't be decomposed evenly into standard denominations. It's not a perfect solution, but it's a reality of blockchain scalability that some UTXOs aren't worth creating or spending. Similarly, I opened an issue in Samourai's repository (which the developers deleted  ) pointing out how their coinjoin client was forcing the creation of uneconomical dust outputs instead of allocating these sats to the mining fee for the premix transaction or the mix transactions.


Yes, I'm not quite sure what the correct formatting is though.

So, what should normally happen? Some other participant creates an output of the same value as mine? I thought that output values follow this denomination standard. I suppose that if outputs have to be those values, then I will always have change in the coinjoin with score 1. (Unless edge cases where the change is exactly one denomination.)

Can I put an onion URI in there?

I'm just wondering: will it ever display that the privacy progress is 100%? If yes, under which circumstances? For all I understand, it should only approach it.

Interesting. 0.01 BTC is not large enough to require creating a change output, so I guess you just got really unlucky and no one else decomposed a matching value for your second output?


Serialization for this field was fixed and will be in the next release: https://github.com/WalletWasabi/WalletWasabi/issues/13530

You can change it back to 127.0.0.1:8333 if you want to choose random P2P nodes.


Gaining anonymity score on part of your balance is preferable to gaining no anonymity score at all. There's two ways to implement the scenario of insufficient privacy gains before signing, depending on whether you want to save mining fees or guarantee privacy. BTCPay Server's implementation will abandon signing the final PSBT if it calculates the outcome would lead to a net loss of score (DoSing the round and waiting out a ban). However, this can leak metadata (failed common input registrations), and could create a positive feedback loop that causes all clients to fail one at a time (in theory).

Although anonymity score is a decent metric, I feel like there are many more properties that should be accounted for besides just the number of matched outputs.

No, I don't think so. I downloaded Wasabi Wallet, latest version v2.3.0, and inserted "https://coinjoin.kruw.io/" in the coordinator URI.

By the way, my Bitcoin P2P Endpoint is "Unspecified/Unspecified/Unspecified/3:8333". I changed it with my local node, but it didn't work for some reason, and I undid it. And this is what it displays since then.

Okay, that makes sense. "Anonymity score" is a vague factor, and it should be calculated very rigorously. My question then is: why does my client allow splitting the input into two outputs if one of them won't meet the "sufficient score" if I can phrase it that way? Wouldn't it make more sense if the input created only one output?

This is very humble, I appreciate you approaching the subject again.


That seems like an unusual decomposition. It sounds like you were using the BTCPay Server coinjoin plugin?


"Anonymity score" is a best attempt to measure the privacy gained from a coinjoin round, but it's extremely conservative in order to handle edge cases. If you got an output with a score of 21, that means that there were 20 other outputs created in that round with the same exact value. If your other coinjoin output kept a score of 1, that means it did not match the same value as any other outputs from the round. Although your unique output was made more difficult to track due to the coinjoin, it's unclear how to calculate the amount of privacy it gains, so the client just assumes it is zero and just remixes the coin. This guarantees that whales who create change will eventually break that change down into amounts that blend in evenly with the rest of the pool.

Anonymity score is also divided by the frequency of your outputs. For example, if you created 2 outputs for 0.01062882 BTC out of 22 matches with the same value, then the anonymity score you receive for each coin would be 11.

I feel the need to apologize for my earlier statement claiming that WabiSabi coinjoins have weak privacy. Specifically, I argued that WabiSabi coinjoins have a lower Boltzmann score compared to Whirlpool. However, this assertion was both gravely inaccurate and failed to make a valid point. Calculating the Boltzmann score for a WabiSabi coinjoin is infeasible due to its large transaction size. Even if such a calculation were possible, attempting to match inputs with outputs would still amount to mere guesswork.

I also want to apologize for likely making many statements about WabiSabi without giving them proper thought or grounding. It seems I misjudged due to insufficient study on my part.

---

I recently gave WabiSabi a try, and I have a question. I joined an input worth ~0.01 BTC using your coordinator, and created two outputs. One of them has an anonymity score of 21, the other has 1. How is this calculated exactly? If it's joined in the coinjoin, shouldn't it be greater than 1? Does this imply it's possible to determine that the 0.01 BTC input created that specific output with high certainty?

I suppose not if your standard of 'perfect' is 100% guaranteed privacy with no thinking involved. However, liquid coinjoins using the WabiSabi protocol create a practically infinite amount of results, you can attempt to trace participants yourself: https://mempool.space/tx/70aad1d92dd3fc6ddbd802ed20ed155472a5752126a0c3489b56fde6e4cf801c

I have read the whole thread and it seems to me that there is no perfect solution between these options(?)

Another Bitcointalk user attempted the challenge of tracing a WabiSabi coinjoin:


He failed to produce any results

A new challenger has appeared! dkbit98 claims Bitcoin is not anonymous. However, he was unable to trace a WabiSabi coinjoin:

Unlike coinjoins with a fixed output size chosen by the coordinator, WabiSabi coinjoins organize output amounts optimistically from the client side. When creating huge rounds with lots inputs, it's easy for clients to match their output amounts with each other. With smaller rounds, the efficiency decreases. For this reason, the default coordinator in Wasabi Wallet requires at least 150 inputs for a round to begin, but other coordinators may require lower input minimums. For example, this WabiSabi coinjoin only has 40 inputs: https://mempool.space/tx/9709771a2dc9a1343327776a1f52e6ae75adb981cabdab449408099d5851baf2

Oh, yes. The censorship chapter of this saga, unending. "You shouldn't coinjoin if you're a criminal" <-- they've literally said that. If you read that post, you can see Max arguing that Bitcoin is permissioned, and you can send "bad coins" only if you own hashrate or bribe a miner. And we're supposed to trust the skills of these clowns.

Oh, and since I've sent you to that post already, read my favorite part:

There is no solution to which coins are good and bad, but let's buy chain analysis crap data and grant them control over who gets to coinjoin and who doesn't.  

You don't have to trust me.


You don't have to trust Wasabi. It's trustless open source software.

At this point, any body who reads a discussion in which Kruw has participated and decides Kruw is to be trusted deserves the future consequences of their own stupidity.  Such as nodding their head in agreement to Kruw back when he pointed fingers at us for arguing against Censorship.  Whoever stood for the childish arguments Kruw had back then looks pretty silly now when you have Kruw himself running an uncensored coordinator, which is doing the exact opposite of what he said himself, which was that Censorship is the morally correct thing to do.

We both know Wasabi is NOT to be trusted and I would definitely have many other options over it.  Hell.  I would rather trust a Centralized Exchange which says up front that they impose Know Your Customer than some body like Kruw and the Services he advertises.  Particularly when equal or better competitors to Wasabi always get a spit in the face from Kruw with no reason when ever he gets the chance to do it.  I like people being up front.  Particularly when I decide whether to choose their product or not.  Tell me you arbitrarily ask for Know Your Customer and I will be an idiot if I drop my money thinking I will not be asked for it.  But when I ask a question and it always gets derailed, how the hell am I supposed to trust?  When Wasabi claims to be THE solution for Fungibility while differentiating one Bitcoin for another and THE Wallet for Privacy while imposing Censorship, which is very 1984 ish, how am I supposed to trust their product?

I forgot.  'Wasabi is TRUSTLESS!'.  Sure.  How dare I even THINK about trust.  I completely forgot their stance was different.  More like, ignore the red flags, shut up, close your eyes and hand us your Money.  Do not ask questions, or else you are an idiot.  And a Scammer, too.  And probably an Alt of Samourai.

Like I previously said.  Kruw could do astonishingly well as a Politician considering the expertise of avoiding any legitimate question, derailing discussions and talking about apples when asked about pears.  This is a skill no body wants but he proudly showcases at all times.

-----

Why can you not answer so many questions and always answer only what is convenient?  The glasses, Kruw.  We are back to where we started, they are either dirty again or you need to get your eyes checked because they seem to skip so many questions all the time.  I am starting to get really worried!

Yes. Why can't you answer that question?

Aren't you tired already from playing it stupid? I mean, Jesus. Do you think the viewers of your discussions can't tell you're one big hypocrite? You're really asking me to answer why I would rather use Whirlpool over WabiSabi, after all been said for the last two (or three?) years?

Literally everything in these questions has been answered in the past. Anyone still trying to figure out those answers can just use a search engine like ninjastic.space. The tl;dr is that Wasabi is a clown fest. I'd rather not engage in discussions about it anymore, if I may. I think I deserve this. There really isn't anything more to say.

Still waiting for the answers to all of these questions.

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.

Why not use WabiSabi instead of Whirlpool so you don't have toxic change and have no lack of privacy at all?


You can't consolidate UTXOs in a Whirlpool coinjoin, there are always an equal amount of inputs and outputs.


Having the coordinator ban Alice because Bob registered an output to her input address doesn't solve the DoS issue.


What possibilities were eliminated by the 262 input collaborators and 294 output collaborators in the WabiSabi coinjoin you linked? https://kycp.org/#/710d395ca20709096a0778927cb960a466be675b188a234b9b52ffb88bb97a3e

You claimed before that these input and output merges are "literally identifiable" but you are literally unable to identify any additional information presented at all from these merges taking place.


It says "no Boltzmann available" for WabiSabi coinjoins on kycp.org.

Personally, I combine toxic change with other toxic change where lack of privacy is minimum. I don't use it that much anymore though, because Monero is simply superior than both of you. There is an entire article on what to do with toxic changes, though: https://bitcoiner.guide/doxxic/.

It has been said multiple times already that it allows you to consolidate them with a mix partner. At this point, you're just repeating the same soundbites. WabiSabi != Whirlpool, so yeah, it doesn't allow you to consolidate just as WabiSabi does.

No. The coordinator would simply refuse to work on a coinjoin where outputs contain addresses from inputs, just as you've programmed it to refuse "naughty" coins.

Nothing is provably revealed, in the sense that I can be 100% sure to ownership identification, just as if I send all of my coins to a single address, you can't tell if it was self-transfer or I spent them to a merchant. But, privacy is about possibilities, and input / output collaborations and merges only worsen uncertainty. There is an entire analysis technique called Boltzmann score that computes resistance to this potential linking. WabiSabi coinjoin is worse in that matter, as it appears in kycp.org.

What should users do with their Whirlpool change since they can't spend it to anyone besides the specific source who originally sent them the coins in the first place?


It is Whirlpool's fault because Whirlpool doesn't allow you to consolidate your coins privately like WabiSabi enables.


Your solution would allow Bob to DoS the coinjoin coordinator by choosing an output address that matches one of the input addresses.


What information was revealed from the 262 input collaborators and 294 output collaborators in the WabiSabi coinjoin you linked? https://kycp.org/#/710d395ca20709096a0778927cb960a466be675b188a234b9b52ffb88bb97a3e

Unless the user approves linking the outputs together. Sure, generally speaking it is a bad practice, because you reveal common ownership, but if you mix regularly and receive coins from a specific source, then consolidating toxic change with other toxic change might be acceptable by the user.

The user chose to consolidate a dozen private coins into one. I agree it was a very bad practice, but it is not Whirlpool's fault.

Yes, do not allow the coordinator to accept creating outputs with the same addresses as the inputs.

Why would Bob pay another input of the coinjoin?

WabiSabi coinjoins literally have identifiable input and output merges, which I agree that they happen on multiple coinjoins that obscure the ownership, but reveal quite a lot of information. See kycp.org/#about on input / output collaborations and merges.

Whirlpool change should ABSOLUTELY NOT BE SPENT with other change because it will link both payments that created those change outputs together.  Satoshi identified this common input heuristic in the Bitcoin whitepaper:


You don't seem to understand, This user already Whirlpooled his coins and he was traced anyways:

Here's the user's Whirlpool premix transaction: https://mempool.space/tx/63679c9ec82f246811acbab0c04cc0fc77ba050e1b6c23661d78afcfc13cf8aa
Here's the Whirlpool postmix transaction where the user was tracked: https://mempool.space/tx/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db


It's not a "software problem":  Can you explain how to fix this "software problem" of an address being reused on both sides of a coinjoin?

Alice registers an input from bc1qalice
Bob registers an input from bc1qbob
Alice registers an output to bc1qanonalice
Bob registers an output to bc1qalice

Alice's address is being reused on the input side and the output side of the coinjoin.  Clearly, Alice would want to sign this coinjoin transaction if it pays both bc1qalice and bc1qanonalice since she's getting more money than she expected initially.  Can you explain how Alice receiving extra money would be a "software problem"?


WabiSabi does not share Whirlpool's problem because you can send payments directly to its destination in the WabiSabi coinjoin itself without revealing multiple inputs belong to the same wallet.


Yes, I already educated you how kycp has identified the remixing that WabiSabi users participate that massively increases their privacy:

And it is the user's fault to consolidate badbank change with private coins. Change should be spent with other change, and not with private coins, which is the reason why Sparrow doesn't even allow you to mess that up, unless you deliberately combine them in a separate transaction.

It is very avoidable. You simply choose to never combine change and private coins in one transaction.

The Whirlpool user can gather change, and once the amount is sufficient, send them over to Whirlpool.

Good, so we agree. The problem with Wasabi 1.0 was that it reused addresses in both sides, which is 100% a software problem. The problem with WabiSabi coinjoins is the same as with consolidating Whirlpool private coins without a mix partner; input / output merges, which possibly belong to the same wallet. WabiSabi coinjoins contain lots of them. Have you checked the kycp.org link?

They don't want to create change outputs though because the change addresses in Whirlpool are completely traceable: change can't be spent without linking your transactions together.  These 305 sat and 933 sat Whirlpool outputs are in addresses 100% deterministically linked to the original owner, whereas the 5000 and 6561 sat outputs from WabiSabi are spendable because they are completely anonymous.


Spending received coins and Whirlpool change together links those two transactions together.  This isn't a feature, it's an unavoidable privacy leak.


So you think the Whirlpool user should consolidate their postmix outputs within a WabiSabi coinjoin to add mix partners?  Makes sense.


If a user chooses to reuse a receive address for multiple payments, that's a conscious choice, not a problem with the software. For example, this Whirlpool user combined his traceable premix change output with his postmix outputs that were sent to a reused address:

Whirlpool premix transaction: https://mempool.space/tx/f7e015cc5f84517e45c107e3c8385b49f6f5a1196ef87fe84f495754272387f5
Whirlpool traceable change address: bc1q86n54k0f6gadrkhdsdut9r6ej3d8j68udrxggs
Whirlpool postmix outputs in reused address merged with traceable change: https://mempool.space/tx/983c459268435613fa8a19eebb7d80afae76f684ca5a2481877b37a41aab5e5a

You have already received your reply. Users are free to mess with their privacy and money. The client should not recommend them to do so, but if they nonetheless want to create dust outputs, they are free to do so. In the given transaction, it is clear that this was a conscious choice made by the user.

... yes? That's because spending your received coins and change together is generally considered a feature?

You showed proof of a Whirlpool user consolidating the many post-mix outputs into one, which agrees with my initial statement that the user is free to mess up with their privacy. If you use Whirlpool in Sparrow wallet, trying to consolidating all these will warn you that it will appear as a self-transfer, and instead will suggest you into adding a mix partner.

I don't think there's a problem with the user consciously deciding to harm their privacy and pocket. I think the problem lies with software that harms the user's privacy without them knowing.

What do you think of the dust problem in Whirlpool that wastes money for even smaller outputs?  https://web.archive.org/web/20231025112756/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/461



Using a different derivation path for the change output didn't stop those Whirlpool addresses from being linked together.

Furthermore, I showed the proof of how I linked postmix Whirlpool outputs to the premix transaction that generated it, which no one ever addressed at all:



Okay, since you seem to think there's a problem, what is the solution to the problem you are describing?  How should the coinjoin protocol be changed?

A segwitv0 output is 31 vbytes, but a witness input is around 68. That's 99 vb, multiplied by 37.5 = 3712.5. Yes, it is less than I wrongly calculated, but it is still waste of money for such a small output.

I'm good at quoting old posts as well:

B-b-but, I thought this ethos was unacceptable.  


I know, I know... Just another confusion in the name of privacy!  

BlackHatCoiner, you still haven't followed up on our original conversation about me linking Whirlpool addresses together:



Your math is wrong:  At 37.5 sats/vbyte, it costs 1163 sats to create a segwitv0 output (31 vbytes) and 1612.5 sats to create a Taproot output (43 vbytes).  Smart WabiSabi clients make sure to choose outputs that aren't dust: https://github.com/zkSNACKs/WalletWasabi/issues/10675

However, Whirlpool clients create traceable dust outputs that cost more than their value to create.  I reported this to Samourai, but the bug report was deleted without comment: https://web.archive.org/web/20231025112756/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/461



As you noted already, the service does not choose the addresses, users choose their own addresses:

Come on, kayirigi. Get over it, it's clearly the user's fault!  

What's dust? Gimme my 5000 sat that costed more than double that amount to be created!

Oh! It's supposed to confuse the observers of the coinjoin, that explains everything! Let's start reusing addresses in both inputs and outputs then, as in Wasabi 1.0. That will definitely help, because we will confuse chain analysis even more. Why kind of a clown service reuses addresses in both sides in the first place? That will leave them so speechless that they will give up!

As you demonstrated, you weren't you able to identify the inputs owned by the user who merged their outputs in WabiSabi.

WabiSabi exit: https://mempool.space/tx/9273410e2994fa02fb1baa071d84a44fb4ad12ceba50a46eadfd24cf0dd7efa6
WabiSabi entrance:

As I demonstrated, I was clearly able to identify the inputs owned by the user who merged their outputs in Whirlpool:

Whirlpool exit: https://mempool.space/tx/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db
Whirlpool entrance: https://mempool.space/tx/63679c9ec82f246811acbab0c04cc0fc77ba050e1b6c23661d78afcfc13cf8aa

Only WabiSabi preserved privacy in this case, while Whirlpool leaked the origin of the funds.

So exit merge on Wabisabi good. But exit merge on Whirlpool bad. LOL. And you think people believe this BS from a Wasabi worker?

And you ignore 100% deterministic links. And address reuse. 

Wabisabi is a scam.

BlackHatCoiner, you merited a post above but you haven't responded to your previous conversation:

This is exactly the sort of confusion a coinjoin is designed to cause  You mistakenly thought that multiple inputs being spent together meant that they were linked to the same owner, but a coinjoin has inputs from multiple owners in the same transaction!


Here is the exit merge transaction spending 2 outputs from the coinjoin worth 0.1 BTC each - 9273410e2994fa02fb1baa071d84a44fb4ad12ceba50a46eadfd24cf0dd7efa6 - let's analyze them:

In the coinjoin, there are 13 outputs for 0.1 BTC:

bc1qzy2dlcau905jwaktrlnqd7q2uu8m6296xe0y0t <- Exit merged
bc1qykz79d67prjv73wej032kreyysumvg54wlqsc3
bc1qfdt9na0vqu94y0ltz97fg6ep0nztqrlhj4e6as
bc1q26vktzc3uqhld6kgf0c0zgldh4t7wp665kfwm7
bc1qvged8zxdpcsxc3qe2pl62lsl3neprltrvtspn3
bc1qsl2sp0t87rsau6tusy465p9e5vq7r9y0ldns6a
bc1qjpmncaadtk5ef32km44xa5z0mzsden78ev66ws
bc1q5t00axlmeyg7crkq4rlh2qevdz8lcud8gl2q8h <- Exit merged
bc1qe3s0vlsvu3rhd7w7dsswsgdj5k2t99e0f90a9n
bc1q7whl0n3dvu5n3tjqd4g4r7antz70t96mhepn6v
bc1q7cnu23w5rxlktdhm7322y7spe8kyj98dl6stwf
bc1pdu3xkqcpwd6x9uhhy5rh536nevj9vzqkpqmnqjqkhuwpqp9zgrssjh3gwa
bc1pkmkkpug5z2w6pn80kwlyev7v5nw6rukjae4cha2mz6vusz0ef98q5vcv9d

By consolidating two inputs for 0.1 BTC in the payment, the owner retroactively reveals a coinjoin output value of 0.2 BTC.  Does this cause him to lose any privacy?  Let's check the original coinjoin transaction to find out...

In the coinjoin, there are are 9 outputs for 0.2 BTC:

bc1qxcfcgdqey4yc3cqjknea2spe8mw2r0k7n083t2
bc1qwezuexwx4lvafeg34ctzpny64fu3t9w8ngtngg
bc1qs3ztep3w80pm3wz4htj2h9x4ewdug4hzaphfve
bc1quqzcseygmad87g4plgf9yuxzss5r5q72w9g3w2
bc1qu7uj5tcdj5s2e23t08v0rsneejvfd6n0qrxf36
bc1qu77gevtnq6uky0vpjpl2ru96lus58p38qmpywc
bc1p2mzlp34rqsyv7u28y6xdpypqapc8aeeuczuaaqzkv9snmnsenj2sw0uny9
bc1p742nnv0774t5gk8lt72t02wuupapt47dx00ddsq45zl9gedcw22qp3ayg2
bc1plmzmhejjuqykvnf00mue54egap3kjtl5qtcdzf4q6k7v87q34lqs37z3t5

The user stayed anonymous when merging his two 0.1 BTC outputs together since there's many possible ways to create 0.2 BTC as an output from the inputs of the original coinjoin.  This transaction demonstrates how the "smart clients" arrange their output values so that merging smaller matching outputs together results in creating a larger amount with additional matches!

This exit merge proves that even smaller denominations than 0.1 BTC are now also possible combinations that would add up to 0.2 BTC, adding even more anonymity!  Let's check the original coinjoin transaction again to find some...

In the coinjoin, there are are 13 outputs for 0.05 BTC:

bc1qyttl3f9wu2zm3dwnytavs6eqk00glc3xng43ea
bc1qye0g8qdjdl48c5hx7a69t5ekcgcemfrhx9z6sr
bc1qxrgu0lv0ps50c9nf2efjq5zfdfruxejmfu8g8y
bc1qgpwc5803au9cs95u38yz64jhdjrkpp4j249n9u
bc1qt2wugrvm5nts263he4aj2ky2pghhdl90j0lx03
bc1qvzanwhhyf2tfcds3rts958jun84ves3xtc3gcp
bc1qvgmnh5fzrqzx7uhhrcw6emzmktj4atqpn7ev9m
bc1qdm9ae8rq0403ga5rshvw4vjd507t8chu4fn40k
bc1q0ltpdzchc6eeytaafl7muhscdfejr2w269a8xl
bc1q3z5cj7sx53lq8sqdkmflce0dzsaj6437zzqj3p
bc1qhm4cd97znryr6rx4wqrsjj2shcpl44hhmsf8hz
bc1qcww2qypj47vz52uw5y8m7cn7y8vvfxx7tnrajq
bc1pncyek7s2m3tc9kwkswqnja8309gtmjgsykpa5jyahhv7yuavyugqlfpee5

On top of the possibilities of creating one output for 0.2 BTC, or two outputs for 0.1 BTC, it's also possible a user with 0.2 BTC on the input side created 4 outputs for 0.05 BTC instead!

___________________________________________________________________

How does this compare to Whirlpool exit transactions?  Here's the kycp analysis of the Whirlpool exit transaction I traced in the OP: https://kycp.org/#/ce2f84f7c5ff74fb1da103acb7b279bd34f02f5e9e3a2e1b6417ce8b9b7392db

All 20 postmix outputs merged were a direct descendant the same premix transaction, making it trivial to unmix.  Unlike JoinMarket or WabiSabi, this user is not in control of remixing, he is dependent on the Whirlpool coordinator to push his coins deeper into the pool.

https://kycp.org/#/1ca4743bd12bc54cd19233f0807ae8b7faec7fdce695f72f345b99d0200ef3d5

15 address reuses
13 exit merges
233 inputs linked
236 outputs linked

Cya privacy! Let's do another!

https://kycp.org/#/ad5516f70697af7c9b14297bb4eb1249bee216b7976b7c50f2369a89afb86975

2 address reuses
2 exit merges
This one with extra bonus of 100% deterministic link between input and output!

Cya privacy! And extra extra bonus of HUNDREDS of outputs ground in to dust. 5000sats? 6561sats? Losing money for Wabisabi coinjoins which don't work!

You are lying, the document you linked was published a year before the WabiSabi protocol was in production.

Feel free to try to trace a WabiSabi coinjoin yourself, no one else has been able to do it:

Chainalysis can demix Wabisabi protocol and do this for OFAC. Wabisabi is the only one of three coinjoin protocols which can be demixed like this.

Here is government contract with Chainalysis
https://archive.is/1zU9t

Yes, it doesn't appear the docs are extremely thorough for the coinjoin plugin.  Here's the big red /!\ warning message that appears in BTCPay Server if you try to coinjoin with Tor off: https://github.com/raspiblitz/raspiblitz/issues/3729



Whirlpool clients have Tor disabled by default, so I opened an issue to get a warning added to Samourai Wallet about the privacy leak, but they said that any PR that adds this warning will not be merged: https://web.archive.org/web/20230417145554/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458

There's 0 mention of keyword "tor" or "onion" on it's documentation though https://docs.btcpayserver.org/Wabisabi/. Although i didn't watch included youtube video.

Yep, I'm excluding any wallet level implementation details and focusing on the protocols. As you indicated further on, the most trivial way to forfeit privacy in this process is reuse the same IP address for each "identity" you assume:


Tor is used by default for the WabiSabi coinjoin plugin in BTCPay Server.


Yes, that's the section.  There's 0 marginal cost for an attacker to DoS a WabiSabi coinjoin round just like there's 0 marginal cost to get another plate of food at an all-you-can-eat buffet.  Since you will pay to transfer any UTXO you own at some point anyways, there's no disincentive for attacking with it before giving up ownership in the future.

In the JoinMarket framework, this 0 cost attack applies to malicious takers who propose offers to makers without ever intending to complete them.  Makers will reveal common ownership of their unspent coins to the taker, who never ends up paying the mining fees to mix that maker's coins. See https://reyify.com/blog/poodle and https://github.com/JoinMarket-Org/joinmarket/issues/156 for the defense against this attack.

That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack. At very least, BTCPay doesn't use Tor by default and in certain cases i expect to detect whether it's deanonymization attempt or network problem.


Is that from section 7.1.2? What exactly do you mean by marginal cost?

What mistake did I make?  Use a direct quote and I'll update it with a correction.

The saddest thing of all is that you don't even recognize your mistake, let alone show any remorse. It is pathetic.

But, I still wish for someone to stand by you in your time of need, someone who will love you no matter what.

I care deeply about Bitcoin privacy, that's why I spend so much time to educate people about it.


You don't seem to understand: Equal output coinjoins from JoinMarket, Whirlpool, and WabiSabi have a distinct on chain footprint that distinguish them from all other transactions regardless of whether those transactions are ordinals or not.


You can easily scan the blockchain yourself to identify any equal output transaction (including coinjoins) using this tool: https://supertestnet.github.io/coinjoin-explorer/

Here's what the footprints of each coinjoin protocol look like:

-JoinMarket - https://mempool.space/tx/c270b84767431eae0aabcd4f99f93f1d299518aebb7529650dbbf41815561d03
-WabiSabi - https://mempool.space/tx/d465033214fd2309dcce5a90c45fcaa788aa4394ee36debe07aad8d8a37907d2
-Whirlpool - https://mempool.space/tx/3cef999a3c006be772f7f63fc87b718cd01146ab593644e0eeb3d61e753f02b8

Merely knowing a coinjoin transaction has occurred does not actually make it any easier to determine what happened within the coinjoin transaction.

This is my last post to you since you don't seem to care and I am tired of wasting my time.

You are 100% correct ordinals has absolutely nothing to do with coinjoins.
Ordinals are filling blocks with transactions that are obviously not coinjoins. And the rest is Crateology.
https://en.wikipedia.org/wiki/Crateology

As I said take out ordinals, take out known TXs, take out what else they know from other services and you have a very small pool of txs moving at the moment.
Keeping an eye on all of them and figuring out what is going on where is a lot less difficult then if all the txs in blocks were 'real' transactions.

Could 1 person do it looking at a list? Probably not. Can a lot of people with a lot of computing power and resources following all transactions do it. Probably yes.

You also seem to think that there are not a ton of tor nodes that are not run by and fully monitored by the government too.

-Dave

Ah, I misunderstood: You meant this cost is to set up the attack, not to set up the coordinator itself.


A is the input registration phase, B is the output registration phase, and C is the signing of the complete transaction.  Phase A always ends before phase B begins, which always ends before phase C begins.  Where's the problem?


Ordinals has absolutely nothing to do with coinjoins.

1) Because all the other coins in the coinjoin would be that persons. That is the point.

2) Later people reconnect and sign is the problem. It's usually (not always) not later, it's then and there. a->b->c tend to happen in somewhat real time. So now I know what to look for. And with blocks being full with ordinals at the moment you can probably eliminate 80+% of the TX, take out what are other known addresses and transactions. And the few dozen or hundred at the most can be sorted through at the governments leisure.

-Dave

Setting up a coordinator doesn't cost any BTC, a coordinator just sends messages back and forth to coinjoin participants.


How would you be able to see where every tx came from or where they went?  Did you read gmaxwell's explanation about Chaumian blind signatures?

Should read:

ANYONE can run a Whirlpool coordinator, and they CAN perform a targeted attack where they only choose you to mix in rounds with 4 (or more) decoys so you gain a false sense of privacy.  Or, they could just rug pull you by not mixing your funds after you pay the coordinator fee.

There are probably more then a few people on this board sitting with 50+BTC from the early days who could setup a coordinator



Once again, if I setup a CoinJoin Coordinator for Wasabi users with a bit of tweaking it's not impossible. Getting people to use it would be the issue. But if I am charging no fees I can see where every TX came from and where they went.

---

The right tool for the right job. Hammering together something to make your BTC private will always have flaws / vulnerabilities.
It was not made to be private. Same way a VW Bug was not made to haul lumber. You can do it but why. Rent a pickup truck or a van.
Same here, want more private BTC there are enough BTC -> XRM or other privacy coins -> BTC and done.

---

Not kicking any of the people working hard to do this, but it really seems to be more effort then it's worth.

-Dave

No one sells coins to "mixers": A "mixer" is someone who gets others to deposit coins into their wallet by telling them they will keep their data secret.  Eventually, the "mixer" takes all the coins from the depositers and turns their data over to the government.  We've seen this happen many times before on Bitcointalk:

Jambler is not a mixer. It buys coins from exchanges, miners etc. and sells them to real mixers.

Nope, these descriptions are agnostic of the wallet implementation.  There's multiple wallets that use each of the coinjoin methods I listed above, I'm not getting specific.


What do you mean "as if they even mean something substantial"?  These Whirlpool addresses are linked to each other.


I clicked on the link in your signature, it says "Jambler.io mixing platform".  Did you know this is custodial?


I believe the functionality you're describing is "GroupHug" - https://peachbitcoin.com/blog/group-hug/index.html

However, as the article mentions, this does not provide privacy like WabiSabi and Whirlpool do.  gmaxwell explains the difference here:


Takers in JoinMarket are the coordinator of their own coinjoin, so their threat is reversed (e.g. Feds running multiple maker identities to spy).

Privacy with WabiSabi is guaranteed by your client, it doesn't matter if the coordinator you connect to is a Fed or not because you do not reveal UTXO links to the coordinator or trust them with any data.  

If a Fed was running a Whirlpool coordinator, they could perform a targeted attack where they only choose you to mix in rounds with 4 decoys so you gain a false sense of privacy.  Or, they could just rug pull you by not mixing your funds after you pay the coordinator fee.

There are no more mixer services here, stop trying to die on that hill. Or maybe you forgot to teleport your account to Altcoinstalks?

More on topic:


If there is a service coordinating payjoins between different wallets, which is ultimately what all of these methods boil down to, whose going to be interested in collecting the UTXO history of all the people who participate? Same with CoinJoins and coordinators. Let's say the Fed was running a coordinator, and recorded every UTXO going inside it. Where's the privacy now?

Look. I agree you believe you educate people about Bitcoin privacy, but we have repeated this conversation around solutions for privacy quite a lot of times. The fact that you still quote these whirlpool messages, as if they even mean something substantial, shows with what tenacity you're trying to sabotage Samourai. I agree with Poker Player that the more you talk, the more you ruin Wasabi's reputation.

Quite literally not. There are far more important things in this world.

Except that in your last 13 feedback of your Trust summary, people have accused you of being a horrible human being, regardless. People with no relations with mixers wrote these. Even Poker Player, who carries a Wasabi signature, and could have been considered in disadvantageous position. You cannot keep wandering around with that soundbite. Nobody buys it.

Acknowledging that everyone is going to die versus wishing and praising for someone's death are two separate things. I'm quite struggling to think what else there is to say.

I somewhat agree. People will just assume you shill Wasabi.

---

Have you checked WabiSabi paper from https://github.com/zkSNACKs/WabiSabi/releases/latest/download/WabiSabi.pdf and read section 7?


To be specific, what do you think about sentences i quoted above?

I'm educating people about Bitcoin privacy, just like I always have.  Anonymous money is quite literally the most important thing in the entire world, don't you agree?


Lol, you didn't fall for that did you?  The scammers who promote custodial "Mixer Sites" formed a mob to leave false accusations against anyone who tells the truth that Bitcoin is untraceable.


Everyone is going to die, why do you think that fact means we shouldn't have rationale debates?


The truth about Bitcoin privacy has always inspired hate because the promoters of "Mixing Site" scams don't want their source of income cut off.

Look man, I don't know what you're trying to do here. Don't you have enough with 15 neutral color tags but basically saying you're a piece of shit? Now you want to open a rational debate by quoting someone who is going to die? If it's because Wasabi pays you to represent them on the forum, the best thing you can do is stop doing it. Otherwise you're just going to inspire more hate.

- Public payments made private?
See https://bitcoin.org/en/bitcoin-paper

Transactions on the Bitcoin blockchain have infamously bad privacy. Every historical transfer of coins is recorded publicly and permanently, providing a link between the public keys used as inputs and outputs. Satoshi noted this in section 10 of the whitepaper titled “Privacy”:


- Whirlpool Coinjoins
See https://bitcoinmagazine.com/technical/how-bitcoin-anonymity-sets-work

Whirlpool is a centrally coordinated coinjoin that implements the ZeroLink coinjoin protocol with a privacy restriction that limits the anonymity you can gain. This restriction is called “tx0”, it is a self spend transaction prior to the coinjoin that allows the trusted coordinator to custody the fee they charge in order to prevent DoS attacks from being costless. Once the coordinator’s fee is confirmed, they allow the outputs created from the premix tx0 to be added to their liquidity pools. There are 4 different liquidity pools with fixed output values:

0.5 BTC
0.05 BTC
0.01 BTC
0.001 BTC

The coordinator then chooses between 5 and 8 participants for a coinjoin round who use blind signatures to create an equal sized output whose origin input is anonymous to all parties. In order to incentivize liquidity, these participants are composed of new entrants (takers of liquidity) and remixers (makers of liquidity). The mining fee for the block space used by remixers is paid for by the new entrants, so the value a user receives from their first round does not change after they are selected to remix in future rounds.

- Can Whirlpool be traced?

Yes, the common input ownership heuristic and change output heuristics are revealed by the premix tx0, creating a 100% link between a Whirlpool user’s addresses. Any UTXO that does not precisely add up to a multiple of 0.5, 0.05, 0.01, or 0.001 (+fees) cannot gain complete privacy. There are no advanced calculations required to determine these links between addresses, they are visible to the naked eye:


Postmix transactions can be traced to premix funds when outputs from child rounds of the same premix transaction are consolidated. Consolidation of mixed outputs from the initial round may be unavoidable since users do not have control over whether or not they remix: