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

[Yuval Kogman <nothingmuch@woobling.org>]

On Tue, 4 Feb 2025 at 23:22, Peter Todd <pete@petertodd.org> wrote:

> The supermajority of the people posting on this mailing list are being
> paid for their work. It would be silly to pre-face every single email
> with "sponsored by Foo"; what you are replying to is just an email, not
> my actual review publication, which I have not completed yet.

What I said was:

>> paid for by an interested party as a direct response to accusations I have made

The conflict isn't that you are being paid, but that you're
uncritically repeating unsubstantiated, and even refuted assertions
made by your sponsor, who hired you as a direct response to me
correcting him on those assertions which misrepresent how his service
and the software used to access it both work.

You were also cc'd on the moderated version of the email that you're
replying to which spelled this out in detail, with supporting
evidence. https://gist.github.com/nothingmuch/dcc7c38ab4a689bfc5c13dcb474d134f/revisions

> The amounts involved are tiny, always less than the
> transaction fee, as you can easily see on https://liquisabi.com/

There's a difference between presumed and informed consent, between
presumed consent due to genuine misunderstandings, lies by omission,
and deliberate & persistent misrepresentation of verifiable facts,
that mislead users about what they think they are consenting to.

If the service is really free as users are being told that it is, how
does it generate ~0.2 btc in revenues a month? There's nothing wrong
with earning an income for providing a useful service. What makes it
wrong is that it's misrepresented as being free and trustless. Whether
or not you personally think the amounts are negligible is completely
beside the point, that's for users to decide, which they can't if they
are being misinformed.

> Due to how Wasabi coinjoins work, coinjoins will almost always have some
> small amount of sats left over that didn't decompose into standard
> denominations after the transaction fee is paid.

No, that's not "how Wasabi coinjoins work". This is *entirely* client
side policy. The fact that the policy is so lenient is an
implementation bug (again, a claim I made years ago which was never
argued against) that has no technical justification, and no economic
justification when fees are low. Claiming the excess mining fees for
the coordinator is exploiting this bug.

> Those sats go to the coordinator.

During most of the zksnack's coordinator run, that surplus went
towards *mining* fees, and was widely understood to do so. This part
is entirely server side policy, and possible due to gaps in the
protocol and the client implementation. The coordinator software was
modified to claim those excess mining fees with no justification of
overruling cNACK that had led to it being not merged 6 months prior
https://github.com/WalletWasabi/WalletWasabi/pull/10884#pullrequestreview-1485776991
and that was only publicly documented around 7 months later, after the
zksnacks coordinator shutdown and the removal of explicit coordinator
fees https://github.com/WalletWasabi/WasabiDoc/pull/1841/files and
only fully clarified a month after that
https://github.com/WalletWasabi/WasabiDoc/pull/1859

Again I suggest you read the wabisabi paper, section 7.2.2, because
the you are conflating two kinds of cost that are explicitly discussed
in that section:

> In particular, remember that that fees are part of the coinjoin security
> model: we *need* transactions to be costly enough to prevent sybil
> attacks.

Contributing this excess towards *mining* fees is a meaningful
deterrence against sybil attacks. This is precisely the original
justification I gave for the set of standard denominations I proposed,
where the excess was supposed to be randomized and around fee-rate
dependent overhead of creating ~1-3 TxOuts (and not just <1, which is
what a pure mining fee minimization strategy would dictate, due to
privacy concerns discussed in the previous email relating to the
generalization sub-transaction model that accounts for fees).

Coordinator revenues, unlike mining fees, *reduce* the cost of sybil
attacks if the coordinator is colluding with the sybil attacker. Since
there is no *requirement* to pay an excess, even in the setting where
the coordinator and the sybil attacker are assumed not to be
colluding, where this could theoretically be a deterrent, a sybil
attacker can economize so this only harms users with unmodified
clients.

Claims about the protocol or its implementation work should be
supported by evidence. Opinions on how it's supposed to work should be
supported by a rationale. Of course, this should also have applied to
the discussion of #10884.

> I'll let others decide whether or not you're being dishonest by not
> mentioning the tiny amounts involved, while simultanously claiming I'm
> being dishonest by not mentioning in my email that (as usual) I'm
> getting paid to work on this stuff.

For the sybil deterrence reasons, in particular with regards to the
concern about targeted attacks, and because of the lack of informed
consent, ~0.2 bitcoin of revenue per month can't be dismissed as "tiny
amounts", especially when the service is described as being "free"
specifically order to avoid regulatory overreach (see twitter spaces
link in moderated email) in response to the Samourai trial.

My claim is that you are minimizing these concerns with no
justification, consistent with the minimization your sponsor is doing,
who stands to gain financially.

> Wasabi set the coordinator fee limit to 0% by default in the Jun 2024
> release:

This was done in response to malicious coordinators that tricked the
client into just giving them money, with no value provided and no
other participants, i.e. another client bug. The origin of this flaw
is that verifiably fair computation of coordinator fees by all parties
to the coinjoin was never implemented, see also
https://github.com/WalletWasabi/WalletWasabi/issues/8814#issuecomment-1199635171

It does not follow from the removal of explicit coordinator fees that
the following holds:

> Kruw's coordinator does not charge a coordinator fee.

The fact that one mechanism for extracting revenue from clients was
called coordinator fees and another, underhanded one is not, is
arguing semantics. What actually matters for analyzing sybil concerns
and for users' consent is where the money goes.

What exactly is the problem with clearly informing users about where
the excess actually ends up, and that the protocol requires some trust
in the coordinator's honesty, so that their consent is informed? If
doing so harms revenues, the implication is that consent was obtained
deceptively prior to disclosure.

-- 
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/CAAQdECDH20thrpNJ%2BBv43DqmJfxyTRJ4BgoVjUU8Vz8i4%2BZEGA%40mail.gmail.com.