Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks

[Yuval Kogman <nothingmuch@woobling.org>]

On Mon, 7 Apr 2025 at 12:35, Javier Mateos <javierpmateos@gmail.com> wrote:
> If the coordinator had malicious intentions in the beginning, these have been observed and brought to the table by a community that is always active and vigilant about these crucial issues. I believe this is already part of the healthy culture surrounding Bitcoin.

I don't see a reason to believe the privacy weaknesses I have
described have been exploited, due to the complexity of the attack. If
they are/were exploited as discussed with Sjors above in the thread,
users should be able to find evidence of that in their debug logs in
the case of wasabi. In regards to samourai, as far as I know no
coordinator is operating, and whirlpool functionality has been removed
from the fork that is still maintained.

That said, there also hasn't been much demand to actually fix these
issues. They've been publicly documented for years.

> -Overall Transparency: We need clear answers to questions such as: How are the residual funds calculated and allocated? Which wallet(s) are used? Ultimately, this information should be publicly verifiable on the blockchain.

As far as I know there are currently two compatible client
implementations, wasabi wallet and the btcpay coinjoin plugin. The
trezor feature was removed following the shutdown of the zksnacks
coordinator, as per
https://blog.trezor.io/important-update-transitioning-from-coinjoin-in-trezor-suite-9dfc63d2662f

It's not verifiable on the blockchain. To the extent that on chain
data can be inferred, liquisabi.com provides estimate, but it's just a
likely interpretation (in that it's consistent with well known
behavior of the client and backend implementations), not proof,
although there's no reason to doubt this information (see earlier in
the thread re acknowledgement of the figures' accuracy).

The source code for these clients is readily available, and has been
throughout. Backend code is also available, but it is not possible to
verify what software coordinator operators are running. In Samourai's
case, there are different archives of the source code, since their
self hosted gitlab instance was taken down, so I can't make strong
claims about its authenticity but regardless the service is no longer
in operation that doesn't matter as much.

> -Audit and Review of the Revenue Model: Is the current mechanism (which retains residual funds) the best option? Could the excess be redistributed among users? Should it be handed over to a group of independent auditors, or what alternative is best? These are questions aimed at finding more transparent options, especially if disclosed properly. They could even be addressed through a bounty, for example.

If there is demand for more transparent coordinators, no significant
barriers exist. Anyone switch to the ones that have posted disclosures
instead of misrepresenting the facts, or start their own, and lead by
example by clearly communicating the trust assumptions, e.g. the
coinjoin.nl coordinator does that, but gets very little volume. if
people want to operate for profit coordinators, or one that maybe
donate all the revenue to some specific cause (perhaps sponsoring
contributrions to fix these issues?), that's their business, though
ideally they wouldn't wouldn't advertise their service misleadingly.
Also note that the fee siphoning policy is trivial to revert, which
would mean that a 0 fee coordinator would really have revenue, with
any residues counting towards mining fees (decomposition can also be
improved to reduce these residues, as per #6580).

> -Audit and Review of the Protocol Architecture: The measures above would help and could pave the way for the adoption of technical mitigations.

In regards to wabisabi's architecture, that has already been done with
respect to what's in the paper. What matters more is the
implementation itself, not sure if that's what you meant by
architecture. Over several years I've made many critiques both before
I left (i.e. the aforementioned github links) as well as starting
after the mainnet release (mainly on twitter), but not a single one of
the concern I've raised has been addressed or refuted. My suggestion
would be that people qualified to audit or review should probably
start by verifying or refuting the claims I have already made.

One of the mitigations I described in this thread (using multiple tor
circuits to obtain the round information and introduce consistency
checks between these) was supposedly planned to be implemented, or so
I was told in private, but unfortunately I see no evidence of progress
on that in the github repository. If new contributors are interested
in implementing that, any of the other fixes described here or
elsewhere, I am happy to provide them with more details, but bear in
mind that some of the people still maintaining it dispute the
existence of these issues (the only rationale i've seen is "it's a
lightweigt client", which is irrelevant).

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECB2%3DFPiTkJ5HT813tcK1522j-J1%2B2%3DS%3Dnir6kb33KoQjw%40mail.gmail.com.