path: root/5a/87b0da2ce605b2c2ec98bf923623c964737a57

Delivery-date: Tue, 07 Jan 2025 07:59:44 -0800
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDI23FE35EIBBZM66W5QMGQEAAVW2IQ@googlegroups.com>)
	id 1tVBzb-0006u4-8n
	for bitcoindev@gnusha.org; Tue, 07 Jan 2025 07:59:44 -0800
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e549eac4ae6sf6502665276.1
        for <bitcoindev@gnusha.org>; Tue, 07 Jan 2025 07:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1736265576; x=1736870376; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=;
        b=pT+yXhUKc6meTQJ47Uv+aIFjOnOwrrIy/CPqcQozdQ+EaB99ZNqj+GP7BRXI6hbDnM
         QV9FgWNNhWvDqLEY8G9NjLUJh0s7w94sUi3SjUyUQY2rkbSvuujpzl7DIikDI5DApwJK
         kmItkVpQ3+oSw9/ymbKJlvvRJtpiER9AT2HRhMHyYv1AhAbQnrJEBmObCI3sk5pQLvTC
         kd4dP5vkAz5R3+jtAaihwDdGd7UCAke6sbJRa1+1b79lZEvPyfOT+5nvIFnFVWO/zwN3
         toYcSDNXKtiohO9nwiHZKuy/PPZ1juBTIfNLwggVIvTfOtmfPVeXNuZMifxrP4+rfny7
         CzBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736265576; x=1736870376; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=;
        b=RZfqygOQeD+lUaSaQ1vEk2waeLn7QrZEarPOqPeV91+gRzvfT7IFAza9DPUCpv2OcZ
         M26oe2XTZGSMY44/Er+Scy+MmnfNa+pPttiNqyU8vdFvye0JRA3rfH8Bh00QWai44DM9
         uYLpDJrc82iTHrfm8wWggD1gB7J325xmmw8MW4BFkVD4JSFzNDJzzSDLbZPa0Vpnb8xp
         /wSwzBYupaM2W6BXuF7vuHaozl+6giGf1KZ98EVPXs3EmDuWRfvHWojWwHEAeMpTEQTd
         AwA4KFU3fZiQ/QXZdI0/EaPC2wFU2wNTvyar0GSr6SV9M96lBXj1ZBzaatoOpXYIWW9U
         Iesg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736265577; x=1736870377;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=dD9Lzfp39WmgjboSEkUZ667qBPKLSrjBhhYd/3hCTaM=;
        b=Jsm4rPT/zEWvol1Cc4uFUuLlslQHDjgSC/iVZaclmV29ZB5XRHGiInnnYCcauzSsDE
         61ffE5sPtgcWFJNxIYskftBEIwUx0weLJpTS7lbElc0rSbARMdTxxYYvT/8DsWeXUjuF
         RKCJdp/Cud9UBnjkoEye2bcCxiyp/jZ242H5etWzytDu7NHXLHWySTIAUnog4idxVFnD
         D3Ys0Svr9zjKiBE/tbUbvjJJ8dKU33qKXdfoJmgnrTrLD5rl910LT3wiM63u5VyUl/s5
         UXPR2BtkHcv08/UJhtIieqbum/mEQKlPfZWdGKipxRTCvWGhk9lUB1q3qj4VOLCxpt3x
         H2bg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWnjTDnf21j0EbX1Uc/rZKNRLcMtCCqpQauOr4NKUcKf/il444b/gJvCZ+qaP3EExv+HfJOsp/IzSrX@gnusha.org
X-Gm-Message-State: AOJu0Ywb3Dwj8aOpzWJ9t7J1yueH60qFPpO7IB5qSPIorXG8p+liFG4Y
	/cZa6UJ409yGjpRjykzwcLcYalKW746wzJamK5hqmTEQbxWOTW+K
X-Google-Smtp-Source: AGHT+IFlUyzsFg3Yd51iPji5piQ6O3XyCgjdj3EFhbzJMFQEsEJJ43x/3+iyEAeZ/Qp1l+c+qXU7Lg==
X-Received: by 2002:a05:6902:2e0c:b0:e53:5eca:de59 with SMTP id 3f1490d57ef6-e538c2328a7mr48081868276.13.1736265576517;
        Tue, 07 Jan 2025 07:59:36 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:ab85:0:b0:e47:56ee:7a99 with SMTP id 3f1490d57ef6-e549d7e3dc6ls604755276.0.-pod-prod-02-us;
 Tue, 07 Jan 2025 07:59:33 -0800 (PST)
X-Received: by 2002:a05:690c:690b:b0:6e2:2600:ed50 with SMTP id 00721157ae682-6f3f813688dmr421643147b3.21.1736265573294;
        Tue, 07 Jan 2025 07:59:33 -0800 (PST)
Received: by 2002:a81:ad03:0:b0:6ef:892f:89f3 with SMTP id 00721157ae682-6f3f57ea50dms7b3;
        Tue, 7 Jan 2025 07:56:02 -0800 (PST)
X-Received: by 2002:a05:690c:f87:b0:6ef:4fba:8153 with SMTP id 00721157ae682-6f3f8106fd5mr408126037b3.10.1736265360925;
        Tue, 07 Jan 2025 07:56:00 -0800 (PST)
Date: Tue, 7 Jan 2025 07:56:00 -0800 (PST)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6a5ac106-6f8d-480d-91f6-0b9796977554n@googlegroups.com>
In-Reply-To: <CAAQdECCq5n7zkRJboVwjLMWkGUP7-G2U7tK4Ekf5M9NqLypLQA@mail.gmail.com>
References: <CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com>
 <E26BEB3C-1345-487D-A98C-2A7E17494B5E@sprovoost.nl>
 <CAAQdECCq5n7zkRJboVwjLMWkGUP7-G2U7tK4Ekf5M9NqLypLQA@mail.gmail.com>
Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai)
 deanonymization attacks
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_51232_470179013.1736265360588"
X-Original-Sender: ekaggata@gmail.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.5 (/)

------=_Part_51232_470179013.1736265360588
Content-Type: multipart/alternative; 
	boundary="----=_Part_51233_1321520125.1736265360588"

------=_Part_51233_1321520125.1736265360588
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello nothingmuch, Sjors, list,

Thanks nothingmuch for the writeup on coinjoins with coordinators.
This general topic is rarely covered and while people like me know about=20
it, we (well, I) are/am too lazy to get into the details of what kinds of=
=20
problems exist.


I think there are two distinct categories of weakness here:

1/ the ability of the coordinator to Sybil a targeted user by *not*=20
including other unknown-to-coordinator entities in the join. This can be=20
done by blocking access of those other entities, and/or Sybilling by adding=
=20
their own entities.

This first weakness is absolutely fundamental for all participants *except*=
=20
the coordinator; you can't code/algorithm/crypto your way around it.=20
Justification of that: the essence of this coordination is that it must be=
=20
anonymous for the participants, that is the whole point. Therefore the=20
ability to distinguish between Sybils and non-Sybils cannot exist, in pure=
=20
form. However:

The weakness is ameliorated, but not removed, by using decentralization of=
=20
having oneself be the coordinator for a join. I say "not removed" because=
=20
the Sybil risk still exists, but the bar is set much higher for the=20
attacker, since they have to Sybil the whole ecosystem, i.e. they have no=
=20
control over who else takes part. It is also ameliorated, but not removed,=
=20
by cost imposition (see Joinmarket fidelity bonds e.g.).

What's clear is that this risk is far worse with a static central=20
coordinator for all joins rather than the "each new participant=20
coordinates" model. Also to correct a common imprecision (so not ofc=20
addressed to you nothingmuch, but to the reader): the taker-maker model is=
=20
*not* incompatible with coordinator blinding.

2/ the ability of the coordinator to tag a targeted user by shenanigans=20
with the blinding key, roundID etc.

The story you tell on this is interesting. In short, as per the=20
"fundamental weakness" paragraph above, it's the nature of these systems=20
that the user is anonymous and ephemeral and therefore the only "identity"=
=20
they have is the coin they bring to the join. Given that, attestations=20
being verifiable requires blockchain access as the ground truth. For=20
similar things in Joinmarket's protocol (and rest assured, we had the same=
=20
requirement, basically), we never had to bat an eye, because we could make=
=20
calls on the utxo set at any time, since we *force* users to use full=20
nodes. But as you say, it *should* still be fully possible with various=20
kinds of light client ... so I am wondering why the people working on the=
=20
Wasabi project didn't consider this a sine-qua-non. Why even bother with=20
blinding if you're not going to give the client a surety that the blinding=
=20
is actually doing anything?

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

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

A few more specific Qs/comments:

On the Samourai issue:

> Because the key is not announced a priori, nor is it signed by the=20
participants' spending keys before output registration or signing[^5], the=
=20
server can provide each input with a unique RSA key. Since the unblinded=20
signatures are made by different keys, the server can learn the mapping=20
from inputs to outputs.=20

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

> 2. use of deterministic shuffling in the transaction, ensuring that=20
signatures can only be aggregated in the absence of equivocation (assuming=
=20
the corresponding Lehmer code has enough bits of entropy)=20

That's an elegant idea; I presume it depends on tx size being large enough=
=20
(yeah, bits of entropy), but that certainly isn't an issue for the=20
Wa(bi)sabi design. Couldn't a similar trick be played with the=20
coordinator's receiving address (assuming that wasabi still works like=20
that, with a coordinator fee address in the tx)?

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

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

Cheers,
waxwing/AdamISZ



On Monday, January 6, 2025 at 8:31:34=E2=80=AFAM UTC-6 Yuval Kogman wrote:

> On Mon, 6 Jan 2025 at 14:08, Sjors Provoost <sj...@sprovoost.nl> wrote:
>
> > Do we know based on observations or published server-side code whether
> > this key was:
>
> > 1) the same for all time; or
> > 2) unique for each round; or
> > 3) unique for each registration request
> >
> > In case of (1) and (2) it would have been possible to detect a targeted=
*=20
> attack,
> > of course only if you were on the lookout.
>
> Only (2) would be correct behavior. If (3) was performed, then that is
> just the tagging attack. If (1) was done, then that would have allowed
> clients to stockpile blind signatures in earlier rounds, and register
> excess outputs during the output registration phase of later ones to
> disrupt them (wasabi 1 had this bug FWIW).
>
> if the archived code is considered reliable, then it seems (2) was the
> implemented behavior:
>
>
> https://github.com/Archive-Samourai-Wallet/whirlpool-server/blob/develop/=
src/main/java/com/samourai/whirlpool/server/beans/Mix.java#L67
>
> > Perhaps if the app kept sufficient logs, it would still be possible to=
=20
> retroactively
> > check this.
>
> I'm not aware of any such observation efforts. They would require
> modifying the client, at least with the archived version that I saw
> the `blindingParams` member is not used that way (there are other
> debug logs in the whirlpool client, but not with this data).
>
> However, since the public key is only given in response to input
> registration, i.e. after the server has learned of the intended UTXO,
> and because in many cases an xpub linking that coin may have also been
> revealed to the server, and the server controls the grouping of coins
> into sets of 5, it seems to me that if it was controlled by a rational
> attacker it would not use the overt key tagging attack when covert
> ways of deanonymizing are available and just as effective.
>
> > * =3D I=E2=80=99m thinking of an active attacker who wants to track spe=
cific UTXOs.
> > They could preemptively =E2=80=9Cpersuade=E2=80=9D the coordinator serv=
er to provide
> > a different RSA key or round ID if they ever try to join a round.
>
> While this is certainly possible, maintaining plausible deniability is
> easier if the server merely maliciously control the placement of
> UTXOs, ensuring that targeted UTXOs end up only with xpub-revealed
> and/or adversary controlled peers.
>
> > Are these round IDs logged by clients?
>
> In the case of wasabi, both my recollection and a cursory search
> indicates that yes:
>
>
> https://github.com/WalletWasabi/WalletWasabi/blob/42e7963d7fffc7f8f37fd9b=
6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L36
>
> I did not check in detail where this information is logged, and I
> don't think a list of all published round IDs is logged.
>
> I would not encourage users to share such logs, or their data, without
> careful considerations. Even if logs were scrubbed, revealing a/the
> set of rounds in which a user participated can significantly harm
> privacy, especially since participation in rounds and coin selection
> does not take into account history intersection attacks. See also
> these issues re log scrubbing
> https://github.com/WalletWasabi/WalletWasabi/issues/6770
> https://github.com/WalletWasabi/WalletWasabi/issues/6670 (first was
> closed without fixing, deemed duplicate of 2nd - i'd say it isn't -
> which is still open...).
>
> One of the developers still working on wasabi indicated that there
> will finally be some efforts to mitigate this class of attack:
>
> 1. redundant queries from isolated tor circuits of the round status
> information where round IDs are published, and consistency checks for
> the data returned
> 2. use of deterministic shuffling in the transaction, ensuring that
> signatures can only be aggregated in the absence of equivocation
> (assuming the corresponding Lehmer code has enough bits of entropy)
>
> Since round IDs are published ahead of time in the status requests,
> and clients explicitly choose which round to join before revealing any
> of their intended inputs, the first mitigation is straightforward and
> would present a significant barrier.
>

--=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/=
6a5ac106-6f8d-480d-91f6-0b9796977554n%40googlegroups.com.

------=_Part_51233_1321520125.1736265360588
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello nothingmuch, Sjors, list,<br /><br />Thanks nothingmuch for the write=
up on coinjoins with coordinators.<br />This general topic is rarely covere=
d and while people like me know about it, we (well, I) are/am too lazy to g=
et into the details of what kinds of problems exist.<br /><br /><br />I thi=
nk there are two distinct categories of weakness here:<br /><br />1/ the ab=
ility of the coordinator to Sybil a targeted user by *not* including other =
unknown-to-coordinator entities in the join. This can be done by blocking a=
ccess of those other entities, and/or Sybilling by adding their own entitie=
s.<br /><br />This first weakness is absolutely fundamental for all partici=
pants *except* the coordinator; you can't code/algorithm/crypto your way ar=
ound it. Justification of that: the essence of this coordination is that it=
 must be anonymous for the participants, that is the whole point. Therefore=
 the ability to distinguish between Sybils and non-Sybils cannot exist, in =
pure form. However:<br /><br />The weakness is ameliorated, but not removed=
, by using decentralization of having oneself be the coordinator for a join=
. I say "not removed" because the Sybil risk still exists, but the bar is s=
et much higher for the attacker, since they have to Sybil the whole ecosyst=
em, i.e. they have no control over who else takes part. It is also ameliora=
ted, but not removed, by cost imposition (see Joinmarket fidelity bonds e.g=
.).<br /><br />What's clear is that this risk is far worse with a static ce=
ntral coordinator for all joins rather than the "each new participant coord=
inates" model. Also to correct a common imprecision (so not ofc addressed t=
o you nothingmuch, but to the reader): the taker-maker model is *not* incom=
patible with coordinator blinding.<br /><br />2/ the ability of the coordin=
ator to tag a targeted user by shenanigans with the blinding key, roundID e=
tc.<br /><br />The story you tell on this is interesting. In short, as per =
the "fundamental weakness" paragraph above, it's the nature of these system=
s that the user is anonymous and ephemeral and therefore the only "identity=
" they have is the coin they bring to the join. Given that, attestations be=
ing verifiable requires blockchain access as the ground truth. For similar =
things in Joinmarket's protocol (and rest assured, we had the same requirem=
ent, basically), 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 c=
lient ... so I am wondering why the people working on the Wasabi project di=
dn't consider this a sine-qua-non. Why even bother with blinding if you're =
not going to give the client a surety that the blinding is actually doing a=
nything?<br /><br />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 given 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 proofs. Well, if the coordinator lies about P, the user2 can =
find out later that day, using a full node or block explorer to check user1=
's utxo. Now, if the coordinator's message is *signed* so as to be non-repu=
diable, then user2 can prove to the world that the coordinator lied. Condit=
ional on that signing, I think this counter-argument is strong; in the abse=
nce of signing, with repudiable messages instead, then I think it's weak.<b=
r /><br />I guess all this comes into particularly sharp focus now that we =
have various different Wasabi coordinators. They should all be assumed to b=
e run by the Feds, so to speak, and analyzed from that perspective. (not th=
at that wasn't true with only 1, just that it's more true, now).<br /><br /=
>A few more specific Qs/comments:<br /><br />On the Samourai issue:<br /><b=
r />&gt; Because the key is not announced a priori, nor is it signed by the=
 participants' spending keys before output registration or signing[^5], the=
 server can provide each input with a unique RSA key. Since the unblinded s=
ignatures are made by different keys, the server can learn the mapping from=
 inputs to outputs. <br /><br />My gut reaction is to do "permanent key twe=
aked with context" here, so the client could easily verify, based on rememb=
ering the permanent key, that the correct (hash of date plus round number p=
lus whatever) had been applied. But that works in Schnorr family, I don't k=
now if a key tweak can be applied to RSA? Perhaps this question is academic=
, but I want to know how easily this could have been fixed in practice. (I =
don't know why they were using RSA, but I could imagine various practical r=
easons; there were after all known attacks on Schnorr blinded signing).<br =
/><br />&gt; 2. use of deterministic shuffling in the transaction, ensuring=
 that signatures can only be aggregated in the absence of equivocation (ass=
uming the corresponding Lehmer code has enough bits of entropy) <br /><br /=
>That's an elegant idea; I presume it depends on tx size being large enough=
 (yeah, bits of entropy), but that certainly isn't an issue for the Wa(bi)s=
abi design. Couldn't a similar trick be played with the coordinator's recei=
ving address (assuming that wasabi still works like that, with a coordinato=
r fee address in the tx)?<br /><br />&gt; it seems to me that if it was con=
trolled by a rational attacker it would not use the overt key tagging attac=
k when covert ways of deanonymizing are available and just as effective. <b=
r /><br />It seems I missed something, here. What covert attacks are possib=
le except for Sybilling, excluding other users from the round? - which is o=
nly at best semi-covert. Maybe stuff like timing and tor?<br /><br />Cheers=
,<br />waxwing/AdamISZ<br /><br /><br /><br /><div class=3D"gmail_quote"><d=
iv dir=3D"auto" class=3D"gmail_attr">On Monday, January 6, 2025 at 8:31:34=
=E2=80=AFAM UTC-6 Yuval Kogman wrote:<br/></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;">On Mon, 6 Jan 2025 at 14:08, Sjors Provoost &lt;<a=
 href data-email-masked rel=3D"nofollow">sj...@sprovoost.nl</a>&gt; wrote:
<br>
<br>&gt; Do we know based on observations or published server-side code whe=
ther
<br>&gt; this key was:
<br>
<br>&gt; 1) the same for all time; or
<br>&gt; 2) unique for each round; or
<br>&gt; 3) unique for each registration request
<br>&gt;
<br>&gt; In case of (1) and (2) it would have been possible to detect a tar=
geted* attack,
<br>&gt; of course only if you were on the lookout.
<br>
<br>Only (2) would be correct behavior. If (3) was performed, then that is
<br>just the tagging attack. If (1) was done, then that would have allowed
<br>clients to stockpile blind signatures in earlier rounds, and register
<br>excess outputs during the output registration phase of later ones to
<br>disrupt them (wasabi 1 had this bug FWIW).
<br>
<br>if the archived code is considered reliable, then it seems (2) was the
<br>implemented behavior:
<br>
<br><a href=3D"https://github.com/Archive-Samourai-Wallet/whirlpool-server/=
blob/develop/src/main/java/com/samourai/whirlpool/server/beans/Mix.java#L67=
" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.go=
ogle.com/url?hl=3Den&amp;q=3Dhttps://github.com/Archive-Samourai-Wallet/whi=
rlpool-server/blob/develop/src/main/java/com/samourai/whirlpool/server/bean=
s/Mix.java%23L67&amp;source=3Dgmail&amp;ust=3D1736348291610000&amp;usg=3DAO=
vVaw2pzsJ4HVDMAHKdcZK8feY1">https://github.com/Archive-Samourai-Wallet/whir=
lpool-server/blob/develop/src/main/java/com/samourai/whirlpool/server/beans=
/Mix.java#L67</a>
<br>
<br>&gt; Perhaps if the app kept sufficient logs, it would still be possibl=
e to retroactively
<br>&gt; check this.
<br>
<br>I&#39;m not aware of any such observation efforts. They would require
<br>modifying the client, at least with the archived version that I saw
<br>the `blindingParams` member is not used that way (there are other
<br>debug logs in the whirlpool client, but not with this data).
<br>
<br>However, since the public key is only given in response to input
<br>registration, i.e. after the server has learned of the intended UTXO,
<br>and because in many cases an xpub linking that coin may have also been
<br>revealed to the server, and the server controls the grouping of coins
<br>into sets of 5, it seems to me that if it was controlled by a rational
<br>attacker it would not use the overt key tagging attack when covert
<br>ways of deanonymizing are available and just as effective.
<br>
<br>&gt; * =3D I=E2=80=99m thinking of an active attacker who wants to trac=
k specific UTXOs.
<br>&gt;      They could preemptively =E2=80=9Cpersuade=E2=80=9D the coordi=
nator server to provide
<br>&gt;      a different RSA key or round ID if they ever try to join a ro=
und.
<br>
<br>While this is certainly possible, maintaining plausible deniability is
<br>easier if the server merely maliciously control the placement of
<br>UTXOs, ensuring that targeted UTXOs end up only with xpub-revealed
<br>and/or adversary controlled peers.
<br>
<br>&gt; Are these round IDs logged by clients?
<br>
<br>In the case of wasabi, both my recollection and a cursory search
<br>indicates that yes:
<br>
<br><a href=3D"https://github.com/WalletWasabi/WalletWasabi/blob/42e7963d7f=
ffc7f8f37fd9b6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L36" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://github.com/WalletWasabi/WalletWasabi/blob/=
42e7963d7fffc7f8f37fd9b6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.=
cs%23L36&amp;source=3Dgmail&amp;ust=3D1736348291610000&amp;usg=3DAOvVaw1A5o=
rHNufy6VbLhxVC_P4_">https://github.com/WalletWasabi/WalletWasabi/blob/42e79=
63d7fffc7f8f37fd9b6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L3=
6</a>
<br>
<br>I did not check in detail where this information is logged, and I
<br>don&#39;t think a list of all published round IDs is logged.
<br>
<br>I would not encourage users to share such logs, or their data, without
<br>careful considerations. Even if logs were scrubbed, revealing a/the
<br>set of rounds in which a user participated can significantly harm
<br>privacy, especially since participation in rounds and coin selection
<br>does not take into account history intersection attacks. See also
<br>these issues re log scrubbing
<br><a href=3D"https://github.com/WalletWasabi/WalletWasabi/issues/6770" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://github.com/WalletWasabi/WalletWasabi/issue=
s/6770&amp;source=3Dgmail&amp;ust=3D1736348291610000&amp;usg=3DAOvVaw37Ajp3=
mNpCYiUv7cFyzCYr">https://github.com/WalletWasabi/WalletWasabi/issues/6770<=
/a>
<br><a href=3D"https://github.com/WalletWasabi/WalletWasabi/issues/6670" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://github.com/WalletWasabi/WalletWasabi/issue=
s/6670&amp;source=3Dgmail&amp;ust=3D1736348291610000&amp;usg=3DAOvVaw3Mk47e=
e2TlN1_bOd-C9ikW">https://github.com/WalletWasabi/WalletWasabi/issues/6670<=
/a> (first was
<br>closed without fixing, deemed duplicate of 2nd - i&#39;d say it isn&#39=
;t -
<br>which is still open...).
<br>
<br>One of the developers still working on wasabi indicated that there
<br>will finally be some efforts to mitigate this class of attack:
<br>
<br>1. redundant queries from isolated tor circuits of the round status
<br>information where round IDs are published, and consistency checks for
<br>the data returned
<br>2. use of deterministic shuffling in the transaction, ensuring that
<br>signatures can only be aggregated in the absence of equivocation
<br>(assuming the corresponding Lehmer code has enough bits of entropy)
<br>
<br>Since round IDs are published ahead of time in the status requests,
<br>and clients explicitly choose which round to join before revealing any
<br>of their intended inputs, the first mitigation is straightforward and
<br>would present a significant barrier.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/6a5ac106-6f8d-480d-91f6-0b9796977554n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/6a5ac106-6f8d-480d-91f6-0b9796977554n%40googlegroups.com</a>.<br />

------=_Part_51233_1321520125.1736265360588--

------=_Part_51232_470179013.1736265360588--