Quote from: BlackHatCoiner on Today at 12:18:46 PM

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.

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:

Quote from: satoshi

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.

Quote from: BlackHatCoiner on Today at 12:18:46 PM

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

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

Quote from: BlackHatCoiner on Today at 12:18:46 PM

Good, so we agree. The problem with Wasabi 1.0 was that it reused addresses in both sides, which is 100% a software problem.

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 used 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"?

Quote from: BlackHatCoiner on Today at 12:18:46 PM

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?

WabiSabi does not share Whirlpool's problem of revealing input consolidation in payments because you can send payments directly to its destination in the coinjoin itself.

Quote from: BlackHatCoiner on Today at 12:18:46 PM

WabiSabi coinjoins contain lots of them. Have you checked the kycp.org link?

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

Quote from: Kruw on October 12, 2023, 12:23:48 PM

Quote from: BlackHatCoiner on October 12, 2023, 12:12:30 PM

Quote from: Kruw on October 11, 2023, 10:04:54 PM

Where's the flaw? All those outputs are private.

There are 262 input and 294 output collaborators

That's called "remixing", those 262 inputs and 294 outputs gained even more privacy by participating in multiple coinjoin transactions. It's not a flaw, it's an advantage, because someone trying to track the flow of someone's coins now have to consider inputs from previous transactions and spends from future transactions.