path: root/c4/43b9fe5281ff0e052fbf07ef8658cb9f58e8b3

Delivery-date: Tue, 07 Jan 2025 13:40:47 -0800
Received: from mail-qv1-f61.google.com ([209.85.219.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDDJ7LVFRIHRBVN6625QMGQECDTXRKY@googlegroups.com>)
	id 1tVHJe-0005rp-EU
	for bitcoindev@gnusha.org; Tue, 07 Jan 2025 13:40:47 -0800
Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6dcccc8b035sf4139706d6.1
        for <bitcoindev@gnusha.org>; Tue, 07 Jan 2025 13:40:45 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1736286040; cv=pass;
        d=google.com; s=arc-20240605;
        b=C+L1IU2v7VvrzkJynIugTJpKd26vxdf5HEPlRUNoy6Ose5NyoRVjdR8X4O6WXDplPg
         SHZhXbxX1XEFblEHH6rwhBbt4S4jj3qGYcX2K1yqvLRtVut7tPotPTP3QLURf3GXKT0U
         /+pPvDnqpjD/JDQnCBC9Cr5RByQzVv93gfyfQooAoH1WCYe5l8FLnC+GFLBqoM75ce8+
         EK3rMTYHei2N1wfMV+0NwmXFp5f4aaFF4k+ucHzJYAEhCgPOuopxzEzs81f18kQxRYpV
         Wc2uHn+zc4c6T19RZEx9BnNzH8vdWOva4hUXxzSNx56+qSLBKH665P61zzA8GNDJu/5S
         7eAA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:content-transfer-encoding:cc:to
         :subject:message-id:date:from:in-reply-to:references:mime-version
         :sender:dkim-signature;
        bh=GFRv9si1Pi50fnMqAtWDU5DDSfMSeR4EVHnK5YIJuq4=;
        fh=J7rzAZporw2PI4rGqG/XBewx/diRCo44q/baMn6rVq0=;
        b=dTqWhyboyZBJ9Zury/7EbYBEg2zEzm/L1QMnI9Qjegh0HKwd2dOkNluJVphNoD8yaZ
         ckIVYGc69XrShkJNA/nhT2wkjtg7adV0W2AGWq3d0XQNZPZqM89YGUPowmpLw3ao07Gy
         Te9+U/ROyEWkr6QFWxxZQI1fKs0cwGNsDiNhARHhrVH1Weyk6Daz2PpkSaB+ZLDGxnP+
         k9b2a4x4gR2luPHaFCf9FuHIMmefkxANYcMhvh9J5BgdbgIiZqUa4al3POvNhEeB/vTX
         UQkRuZdfhCLvBscxqi04ZfecYtOu8tf2AMFliT6zBXVIgFwHYJyeotl4aedaT2NVdd3L
         A5cg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@woobling.org header.s=google header.b=EO6y0TTM;
       spf=none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) smtp.mailfrom=nothingmuch@woobling.org;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1736286040; x=1736890840; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GFRv9si1Pi50fnMqAtWDU5DDSfMSeR4EVHnK5YIJuq4=;
        b=Ek08Dmq6tAy7RnQMoO2oPCjhdWLePco3PZe0UU4vO8nEWNtSZNoC1IUDh4laN3QG4v
         +OJRhTCLC4VeQTXB/36RnSXPdif7bNtd4bu/tpArhjynu9NMTL1a34YCJRqP4sXG2jeQ
         /SiU6eW/f48oOMymZlM+SOP1CHp9XvfhLv0bulGbvIhqhcn29uISRhTnco/w+cmg4utt
         KyUmhZWNdy1iE7sHzxZCnNnbOzP2T6kWMSQlJ/Ob2y0v4Wdg5Wq1VrR19Mv4qLqyePUp
         qlFm5q4RgGxFQeMiVWkp/92TGGV8ShBiVCdjYfusHLtBx+9cuG5NZiE4A7H2BO/fClKW
         Y59Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736286040; x=1736890840;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=GFRv9si1Pi50fnMqAtWDU5DDSfMSeR4EVHnK5YIJuq4=;
        b=coRDo3cyAPLr36yCWoi7cvBXo362HeaCprJ+DARBYz4xK9MzbJI4EmowFOjVA7ZlRV
         niPaFUJPLljJVqKBU5XNjuw72qjFiQ3MWtj+eOnMErwpQ9PtAc/N5ZiPB5uEP3k+XXsM
         0QGINeSEl+gIICxqN1KnQ/OHoBK+m+RRKN3/0RbUT7u6ZkheTDZs0+r6TzMrxb16RvP1
         Y63oqLNl/cS1K00R+q16YURD6lC/faVdizHrViYWd8N7+s5pGNvlxXfZwJ1+q9zzPB27
         GNQHW6jpFmdHqPWjYxWV6/JPajpbL+Oy4nMipDLoGSlbh6oU5JWaslDZ6bU7DFRwkU+T
         7VhQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVFbs2ZD5LnLo/hkPD5w0PJsSMlZxJvo3o7BOiy7WjLLO1F+T3wl0IIFpGFX5EVpNfHyTkGx0jT2e2E@gnusha.org
X-Gm-Message-State: AOJu0YyA8ILG3Og703QRMg3CAy9S9k3pldyDaxeo6piwtkpirbcStXcD
	a6R8+xNcIDJHj7Z2ZQISJZftVoXKn4tk40m96vnYsbSBVzMmn2hA
X-Google-Smtp-Source: AGHT+IH5WWWmKGlvxMmhxqivsu+Fgl6N2uhfC4Jw6nozZpTEORn2u49k27qzgzZGQ/zHBr9EbnXtxA==
X-Received: by 2002:a05:6214:2f91:b0:6d8:99cf:d2d0 with SMTP id 6a1803df08f44-6df9ae3a6f9mr13244266d6.19.1736286039670;
        Tue, 07 Jan 2025 13:40:39 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:420b:b0:469:63f:ce07 with SMTP id
 d75a77b69052e-46a3b07bc42ls28772711cf.0.-pod-prod-00-us; Tue, 07 Jan 2025
 13:40:37 -0800 (PST)
X-Received: by 2002:a05:620a:2550:b0:7b6:e616:4e67 with SMTP id af79cd13be357-7bcd8cb141emr114776185a.2.1736286037040;
        Tue, 07 Jan 2025 13:40:37 -0800 (PST)
Received: by 2002:a05:620a:8408:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7bb90ef4a45ms85a;
        Tue, 7 Jan 2025 13:33:57 -0800 (PST)
X-Received: by 2002:a05:600c:1c14:b0:434:f0df:a14 with SMTP id 5b1f17b1804b1-436e26786a3mr1613225e9.2.1736285635524;
        Tue, 07 Jan 2025 13:33:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1736285635; cv=none;
        d=google.com; s=arc-20240605;
        b=lCaRBLWzVRaOLToFAODPqYuyE7R1XQfFJcJe3pdu4KYp5bvLuMDWj3vgpj6d7k82/B
         7cj4BS/pFfm1DDVqgbwiAcdZcLQ+e8lynFD+6Q6Vrij4CTDezUP4bgbU9O23355N+UJX
         Smqv6uqHdnEGfoGJndaaB5rq52lgB5iBVkNW49Db2ZFY7C1oeDdRwtpMO3N+1ZM8aoQD
         /zHdCoFdWiMeNhuCatkuJ2bY3gaz1Wl3k8qT4fUJUEBE7MiFdX6VxH/P6gXCtUYjDvjn
         nlbgpx47Q0LM5I9zwhH1VTmfHXgFHVjEkp0IkxQ8MBlWUSBihxIDBeOSraYAf7UOiMcs
         YTxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=+R3eNiRlAu/CNfqhXM1iGPkinFQBNZIrHV1XchhBb7c=;
        fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=;
        b=RxjMyAbJgqvETgXusgbhGtanDMPb3hiKtVmwfxqZX3SYk4UA7QmrSadiI3kDjY7MR0
         RJ8vChW23z/4q/UREwmLdvHJbU9CBnY8bkz9URsPEFqqt6yB6zkd/QO7EbKzFSbdhtd0
         PmT3l56gXneQFjNPIB7t+kHFN/5UfLUV/kt9scuqu/kuQNx2500KZM9ZpIn4yVVjr+Y1
         yWJQeKNjVdo0dLEOjxsxHhRCwT0Ipbbnkm+t45YZB9A3xJF1RDuA6kRRPTKNXLimgqLL
         R5Nc7Uc5hGGDH9+BM6hb+9FsvzETpMaqBAnJLHrI0gCDynPRFFp3UFGjuiI8lmoTJ0GW
         /GvQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@woobling.org header.s=google header.b=EO6y0TTM;
       spf=none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) smtp.mailfrom=nothingmuch@woobling.org;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com. [2a00:1450:4864:20::136])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43656b01759si8081925e9.1.2025.01.07.13.33.55
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 07 Jan 2025 13:33:55 -0800 (PST)
Received-SPF: none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) client-ip=2a00:1450:4864:20::136;
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-540254357c8so1841855e87.1
        for <bitcoindev@googlegroups.com>; Tue, 07 Jan 2025 13:33:55 -0800 (PST)
X-Gm-Gg: ASbGnct5Km0XWa4H7m60uTtuzAAiUCz4LwbYuedol5LbmnCTSWimyHYk6nApzynV5AX
	tFQ3dlCUYDLnUZ23fqDmHARd6I53J6rM3Tumiuw==
X-Received: by 2002:a05:6512:2399:b0:542:19ef:9877 with SMTP id
 2adb3069b0e04-542845232d2mr98637e87.17.1736285634368; Tue, 07 Jan 2025
 13:33:54 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com>
 <E26BEB3C-1345-487D-A98C-2A7E17494B5E@sprovoost.nl> <CAAQdECCq5n7zkRJboVwjLMWkGUP7-G2U7tK4Ekf5M9NqLypLQA@mail.gmail.com>
 <6a5ac106-6f8d-480d-91f6-0b9796977554n@googlegroups.com>
In-Reply-To: <6a5ac106-6f8d-480d-91f6-0b9796977554n@googlegroups.com>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Tue, 7 Jan 2025 22:33:42 +0100
X-Gm-Features: AbW1kvYxk30LofiewMBoaRZew27wtk7HHjqpPR3xThvOwjFHR2MR-LKKmXXOwUQ
Message-ID: <CAAQdECAg5W4a9_386FeGWBZnv7zje4gmXtAMcC8scWq_o2dEwg@mail.gmail.com>
Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai)
 deanonymization attacks
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: nothingmuch@woobling.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@woobling.org header.s=google header.b=EO6y0TTM;       spf=none
 (google.com: nothingmuch@woobling.org does not designate permitted sender
 hosts) smtp.mailfrom=nothingmuch@woobling.org;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)

On Tue, 7 Jan 2025 at 16:59, waxwing/ AdamISZ <ekaggata@gmail.com> wrote:
> What's clear is that this risk is far worse with a static central coordin=
ator for all joins rather than the "each new participant coordinates" model=
. Also to correct a common imprecision (so not ofc addressed to you nothing=
much, but to the reader): the taker-maker model is *not* incompatible with =
coordinator blinding.

Nor is it even limited to a centralized coordinator (e.g. if
instantiated with a threshold issuance scheme). Another misconception
is that such a mechanism helps privacy, when all it can do is provide
denial of service resistance potentially without undermining privacy,
but does nothing to actually improve it directly. The misconception is
not accidental, as often wabisabi credentials are portrayed as privacy
enhancing.

> 2/ the ability of the coordinator to tag a targeted user by shenanigans w=
ith the blinding key, roundID etc.
>
> The story you tell on this is interesting. In short, as per the "fundamen=
tal weakness" paragraph above, it's the nature of these systems that the us=
er is anonymous and ephemeral and therefore the only "identity" they have i=
s the coin they bring to the join. Given that, attestations being verifiabl=
e requires blockchain access as the ground truth. For similar things in Joi=
nmarket's protocol (and rest assured, we had the same requirement, basicall=
y), we never had to bat an eye, because we could make calls on the utxo set=
 at any time, since we *force* users to use full nodes. But as you say, it =
*should* still be fully possible with various kinds of light client ...

Indeed. Wasabi has optional full node support, and yet this check was
never implemented. For light clients various reduced soundness
mitigation are possible that would still make it significantly harder
to do this successfully.

> so I am wondering why the people working on the Wasabi project didn't con=
sider this a sine-qua-non.

Well, FWIW I was, it came up repeatedly and I always assumed that it
was supposed to be essential (see the footnote links in initial email
for lots of supporting evidence). The oldest instance I found of me
explicitly mentioning such consistency issues dates back to before the
wabisabi design was in place, and I would think a company with "zk" in
the name and which repeatedly used phrases like "can't be evil" and
"trustless" to describe its service would care, but alas it did not
work out that way. This is especially concerning since everyone
involved knew there was a good chance that alternative coordinators
are very likely in the future.

> Why even bother with blinding if you're not going to give the client a su=
rety that the blinding is actually doing anything?

Ostensibly denial of service protection. If being cynical, DoS
protection only for the coordinator and not the users. But even that
is empirically unmotivated given that the first 3 wasabi protocols had
cryptographic flaws in the denial of service protection, but when DoS
attacks finally arrived they exploited misconfiguration of digital
ocean firewall (no datacenter level firewall was configured) and the
recourse was enabling cloudflare with SSL termination.

The simpler explanation is that it's an affinity scam, and regrettably
I was tricked and exploited into effectively becoming a rubber stamp
of approval with the intent of deceiving non-technical users to pay
the coordination fees. Just one supporting example, note how how an
audit of the code was announced
https://github.com/orgs/WalletWasabi/discussions/7262 but it fails
fails to mention that the audit only accounts for protocol security
that protects the coordinator against malicious users, and that the
non cryptographic but privacy sensitive code protecting clients was
not audited.

> On reflection, I can see at least one counter-argument: suppose user2 is =
looking at user1's signature on the context of the round, and they are give=
n key P for user1's signature and just told "trust me" by the coordinator, =
and they go ahead, because user2 only has a light client and no merkle proo=
fs. Well, if the coordinator lies about P, the user2 can find out later tha=
t day, using a full node or block explorer to check user1's utxo. Now, if t=
he coordinator's message is *signed* so as to be non-repudiable, then user2=
 can prove to the world that the coordinator lied. Conditional on that sign=
ing, I think this counter-argument is strong; in the absence of signing, wi=
th repudiable messages instead, then I think it's weak.

Yep, publishing such signatures would have been a significant
mitigation of the various tagging concerns. i don't remember if
something like this was brought after they decided not to provide
clients with the ownership proofs at all in the initial release.

Ownership proofs were later included, but only covering the threat
model for stateless signers
https://github.com/WalletWasabi/WalletWasabi/pull/8708. Also note how
this commit reverts a fix in the original PR, restoring dummy data in
lieu of a meaningful commitment to the coordinator address, presumably
with this rationale:
https://github.com/WalletWasabi/WalletWasabi/issues/5992#issuecomment-15382=
30320
i.e. it's already broken and released so it's too late to fix
anything).

> I guess all this comes into particularly sharp focus now that we have var=
ious different Wasabi coordinators. They should all be assumed to be run by=
 the Feds, so to speak, and analyzed from that perspective. (not that that =
wasn't true with only 1, just that it's more true, now).

Yep... The most popular coordinator still in use is described by its
operator as "free" and "trustless", and has publicly admitted to be
incapable of understanding these issues. As usual, there is a profit
motive at play, see liquisabi.com for revenue estimates.

> My gut reaction is to do "permanent key tweaked with context" here, so th=
e client could easily verify, based on remembering the permanent key, that =
the correct (hash of date plus round number plus whatever) had been applied=
. But that works in Schnorr family, I don't know if a key tweak can be appl=
ied to RSA? Perhaps this question is academic, but I want to know how easil=
y this could have been fixed in practice. (I don't know why they were using=
 RSA, but I could imagine various practical reasons; there were after all k=
nown attacks on Schnorr blinded signing).>

Afaik RSA was just the obvious choice at the time for both (nopara is
on the public record admitting he copied the RSA blind signing code
from stack overflow... no clue about whirlpool's stated design
rationale). In hindsight, this is arguably better than blind Schnorr,
since Wagner attack mitigation is rather complex though not impossible
(wasabi also had a nonce reuse issue with the blind signing key in the
1st iteration of blind introduced in this PR Schnorr
https://github.com/WalletWasabi/WalletWasabi/pull/1006 and Wagner
attack only became relevant after that)

A tweaked key would indeed work very well for this kind of mitigation,
as the untweaked key could have even been hard coded in the client,
and the client could locally tweak it with the round ID as the
committed data. This should also be possible with blind DH e-cash /
privacy pass tokens, and the wabisabi issuer parameters, which are
just an n-tuple of ECC public keys and similarly amenable to TR style
commitments.

> > 2. use of deterministic shuffling in the transaction, ensuring that sig=
natures can only be aggregated in the absence of equivocation (assuming the=
 corresponding Lehmer code has enough bits of entropy)
>
> That's an elegant idea; I presume it depends on tx size being large enoug=
h (yeah, bits of entropy), but that certainly isn't an issue for the Wa(bi)=
sabi design. Couldn't a similar trick be played with the coordinator's rece=
iving address (assuming that wasabi still works like that, with a coordinat=
or fee address in the tx)?

Yes. It could be an OP_RETURN of course, and not a very costly one. It
could be a pay to contract, if the coordinator is willing to risk not
losing these transcripts, but if published that should not be a
concern, just complexity in the coordinator's wallet. If the
coordinator consolidates any inputs, it could be sign to contract,
eliminating that risk. That said, coordinator fee support has been
removed recently, partly because the fees were never enforced using
the anonymous credential mechanism and client side determination of
the effective values of inputs after deducting such fees, what has led
to abusive coordinators siphoning user funds.

Successfully equivocating transcripts reduces to a multi-collision
attack. For the easiest case, that of a 2-collision to single out
exactly one target user, two transcripts would need to be found such
that the hashes encoded in the order collide. Even if n-1 users are
honest, and the parameters were fully then this is still not a 2nd
preimage attack, since nothing prevents a malicious coordinator from
contributing the last input, and grinding ownership proofs on it to
collide with the transcript observed by the targetted user. log2(40!)
is ~159, just shy of standard NIST recommendations for collision
resistance, note that this is for one list, but inputs and outputs are
two separate ones, so log2(24!) ~=3D 79, would have cryptographic
soundness if there are least 25 inputs and 25 outputs. The main
benefit of this approach is that it saves a round trip, all clients
can just sort the transaction locally and contribute signatures
knowing the transaction would go through only if they all agree, but
this round trip elimination comes with the liability of divulging to
the potentially malicious coordinator what a client had intended to
do.

That said, partitioning all clients is an n-collision, so harder to do
than just finding a 2 collision, and doing "just" 2^80 work in between
learning the final output set and signature aggregation is very
generous to the adversary, but either way the assumption was there'd
be on the order of 100 inputs as a starting condition (in practice
that figure is even higher), so much so that even the current sorting
by amount is retained, just shuffling equivalent valued outputs would
suffice for Lehmer coding a hash image with security level 2^160 (e.g.
~40 equivalence classes of 4 outputs each).

> > it seems to me that if it was controlled by a rational attacker it woul=
d not use the overt key tagging attack when covert ways of deanonymizing ar=
e available and just as effective.

Absolutely, and also note that using any kind of
commit-to-the-transcript-in-the-transaction approach does not
guarantee the coordinator will be caught unless users independently
coordinate to check for consistency after the fact, nor does it
prevent any privacy leaks arising from coin selection, or the choice
of outputs.

> It seems I missed something, here. What covert attacks are possible excep=
t for Sybilling, excluding other users from the round? - which is only at b=
est semi-covert. Maybe stuff like timing and tor?

You didn't miss anything, I only described the long standing active
attacker concern, which I had described before the release due to the
recent "vulnerability" and subsequent "fix": GingerWallet's round ID
hash preimage validation was inexplicably lost in a refactor, and then
restored. They claimed that this active adversary concern was a new
attack, and that it was fully mitigated, neither of which is true.

Usually when I criticized Wasabi in the past, not here, it was over
these passive deanonymization concerns, which IMO are much more severe
than the active ones for precisely the reasoning you gave above.

1. "optimistic" (ugh) approach to coin selection (first select coins,
then try to register, high probability that not all can be registered
due to abrupt cutoff, then figure out how to decompose the resulting
balance), and some ad-hoc tweaks that de-randomize it in order to deal
with some of the fragmentation issues that poor amount decomposition
resulted is a major concern, especially since there's no accounting
whatsoever for history intersection. if the adversary has some
fore-knowledge of a wallet's cluster, then this informs the adversary
of likely output value choices, and subsequent coinjoins or payment
transactions can confirm and further undermine this through history
intersection.

2. initially the tor circuit management was highly problematic, more
recently it has been partly mitigated, but there are still potential
timing leaks especially considering that the guard node will be fixed
for a given client's circuits, reducing total variance for circuits.
before they switched to clearnet coordinator w/ cloudflare + SSL
termination as a trusted middleman this was more severe, due to the 2x
factor in # of circuits required for hidden services.

3. the use of HTTP and JSON at the protocol level, neither of which is
sufficiently rigid to be canonical, and reliance on *varying* 3rd
party implementations of both (i.e.
https://github.com/WalletWasabi/WalletWasabi/pull/13339) between
different versions of the client presents another set of semantic
leaks...

These independent (i.e. potentially compounding) leaks can
additionally be covertly amplified delaying or dropping coordinator
responses (this in particular exploits the lack of request timing
randomization during reissuance or output registration requests, by
delaying responses to credential reissuance requests, if only one
client is actually able to register an output when the first output
registration is received, that's a deterministic link, for example).
If such leaks are insufficient for the adversary to conclude that the
a posteriori outcome is deanonymizable, then it can of course just
disrupt the session forcing a blame round with plausible deniability.
There's some discussions of some of these concerns e.g. here
https://github.com/WalletWasabi/WabiSabi/issues/83

Part of what's so frustrating about my experience is that in addition
to my criticisms seeming like a gish gallop simply because there are
so many flaws, the "rebuttals" against these privacy leaks this were
always in the spirit of "oh yeah? so why don't you deanonymize this
transaction? oh you can't?", which is morally bankrupt given the
profit motive and vulnerable and misinformed users' lives potentially
being  be at risk. More generally, it is well known e.g. from the
mixnet literature that attackers generally have exponential advantage
in every marginal bit of leak information, nevermind the fact that
these concerns are specifically about a malicious coordinator not a
3rd party observer (there the concerns about balance decomposition and
coin selection are still relevant FWIW), which is why in privacy
enhancing technologies usually the burden of proof rests with the
defender, not the attacker.

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAAQdECAg5W4a9_386FeGWBZnv7zje4gmXtAMcC8scWq_o2dEwg%40mail.gmail.com.