path: root/c3/9015045fa52306c60a7325d2dcf28a9805a536

Delivery-date: Thu, 23 Jan 2025 08:56:26 -0800
Received: from mail-oa1-f62.google.com ([209.85.160.62])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRYHVHZTUGRBL7JZG6AMGQE3WE6A7I@googlegroups.com>)
	id 1tb0VF-0000yJ-1w
	for bitcoindev@gnusha.org; Thu, 23 Jan 2025 08:56:26 -0800
Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-29f9dcd1235sf754843fac.3
        for <bitcoindev@gnusha.org>; Thu, 23 Jan 2025 08:56:24 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1737651379; cv=pass;
        d=google.com; s=arc-20240605;
        b=CAMzZPUeld7Rw3OKZjIOBxCpI3sCO3jTgjaA8kkqwwDQdVrH4Fs9MtvJ7rz9AURBE0
         5s2tXoAsLncgeVaaQkmtwXlKrGsUaROPxNTluOrPyAXeOyEg31xzAhBkJKc/N1K4iHki
         pdXDBRuofk+B4vrCReSu7VmSPhClFU2gYIIULn5+eADbe22yiJ33Er0sIDNlvjVJpQjJ
         LoSVhDBUwBTpBVudXiEchvbTqx7hUing2Dia034m9IDMREgCyQfy6h86cjI7r0pkxpM+
         pu3fa/Bw3euND16712s8mDiD6gG8sYuXvMT5mjgrhqHjEDV4kmXMzvFD2AO4Nb6WLnQY
         COPw==
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:in-reply-to:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :feedback-id:sender:dkim-signature;
        bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=;
        fh=xhbugxYcjBiAu97jPwMR6zPtE2yqRMM+O/aiOBitdzY=;
        b=J2er4sVDeQNWSqKR/XM5iY2mMb7gSYfhW7QAQRRL9vP+JwWqVx2NtiIkhXU7ONO5ph
         Dsb44jpfv5rFGRnZKd30H5s16lpIblTPPhgvIW8jkHMU8I0ZqAea6XSix5So6IDw/Oqq
         sZ247C3Wafxu1VxFA244gCNr7E3SmMDrQheYqdDyGsL8c6a+bIdcxQvdjmg94h92mrI3
         1h4WljU2/xgOzXd0ZC9ZxZmJ5TIbZFhMHAqr5rIEHYpVAmwCHaP/KZJyzGZFCl04r9i9
         Y70EWmU0oGfaTcdlqNBv8JbPeRae2vp/ahfGyS1AVvH/q0aG4XWBn2o3tGW7yRt9b0lX
         y4Vg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J;
       spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1737651379; x=1738256179; 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:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=;
        b=jf0WFTnOOyOeBfZbbSzdxzh9ZR/5eFx3tI6z8ZBr571fSHZub/U7ZF9M5ywuL2I9XX
         yvnSxAzUzLfdvq3MHtF6QC8FRKecAXciopdIH/1xHzyiwZhsaVJVGCmcDaK7dGQ8Wc3F
         cFneal0tR4kI1k/dA3uCpD87pvlUchO3x3nIqfzKBREpgPoBiAFlXleFD/yjT4H7/kdD
         eMI4jMnwZDoFhFRuw2mBbAVeGusEoIA053YwRUOwRQ/7CcuXLieQ9zscWWUQOjiVjtmN
         xoeA3UTrX4/eIedoceWlh/5cIg3vvM/zPI+eWSOdJnqqjefpwZYJWl1xd1fLUPHtIeXC
         4LZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1737651379; x=1738256179;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=;
        b=MOSvNS44nP0Zmx1PYS3RB49KYMVO3XKrv/uf3FOJ3aVXHLSCMboy8yhIHaIGfVLhPc
         w9To0Cvi6qzNpkAyBBtkyuWPS1LxqOH/lkXiuJbZ3WE1zaqAUVv9AyxouubWD7o944ZB
         M9A2HIYDFdn57khVfJQ9d7I2JhPkZpOFSLjWPmEwDEuygY2UnMYbVGOdLWbstD+st784
         8lx19xnwV5LiXZDwR8sMfDlU2RlBNCN/IvAE/2xvGRijrZq+A4TcX0H0V4Y6NmvbJ3nB
         evl8iir4lF2w3WgF7gliY4FEckXTqLTooVHScqycO5i5msB9zDevmykfI/Wc3e56lAea
         +K3w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWbBQOcjGUsbL/j+TAp40FxJbI/s8PMOhnyrf4ookCci+nVf7l7KmXd84n2cfEHkspsjkYYpzGGcl8X@gnusha.org
X-Gm-Message-State: AOJu0YzI/ZdbYe5/BBkXXEo6hL6UBIAFKRzrQ/xbPpilsKFfN2Dp8FLv
	t8+xrrQa2MI7JNlNZPydgcrjSatDzLZm3IzfOtak5RpeTdg9oEz7
X-Google-Smtp-Source: AGHT+IFSgW7RE8ykgjURrlkyy6qN7gRV9M3ZBpdbYxTbJd6U6kjkvT3TS+rctIVcTqlPWv0qps9dQQ==
X-Received: by 2002:a05:6870:4f81:b0:296:e10f:af14 with SMTP id 586e51a60fabf-2b1c0b5d5d5mr13991643fac.39.1737651378865;
        Thu, 23 Jan 2025 08:56:18 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6870:ce02:b0:2a0:39b:9275 with SMTP id
 586e51a60fabf-2b273395ed1ls446510fac.2.-pod-prod-02-us; Thu, 23 Jan 2025
 08:56:14 -0800 (PST)
X-Received: by 2002:a05:6808:4d0f:b0:3ec:b672:da89 with SMTP id 5614622812f47-3f19fc55c5fmr11907962b6e.14.1737651374815;
        Thu, 23 Jan 2025 08:56:14 -0800 (PST)
Received: by 2002:a05:6808:1982:b0:3eb:6ba8:8c6b with SMTP id 5614622812f47-3f1e4e874bemsb6e;
        Thu, 23 Jan 2025 08:25:52 -0800 (PST)
X-Received: by 2002:a05:6870:2dcb:b0:288:563b:e48d with SMTP id 586e51a60fabf-2b1c08b0e99mr16384253fac.10.1737649549653;
        Thu, 23 Jan 2025 08:25:49 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1737649549; cv=none;
        d=google.com; s=arc-20240605;
        b=UqG9uyRaEfGox4pYAZ6NLswPId3BEIhcXvNarC7z2le6dWGJNrnaL8h9EubVtvKDFL
         7xwcp9AFs/lrMwTukAlZb+0k7F8etuNVmdFcLEvCWby5qS4eELAna/2r/7uT8ApPYoN8
         qv4Ftp4+y+dJCr62rrgiCrLubx5LiGAXpexh4nNFZh/jqwfDO4hGp78Nv72CvkiJn1ti
         w8DFZGepeAEwqk4j6R4TMi9pjELkKgqCBD/NQuerOvZ6SWIXdBdO+IJbzzKZD83Tty7/
         p19pTf6uS2AGVWm5TMn2l7B91c/9StxRLd5+2/BvPxW+1E4EeJd63TA7nXFgcI1qggCT
         ncYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:feedback-id:dkim-signature;
        bh=FytyV63Y4+uidSjGwaqtiXAk+MefwirtjM3FKAuv+6E=;
        fh=5HyPAjoX9Qu8lrKcSbvwAEk6+YgBxPNZL8TnxYb/Mm4=;
        b=fG7n1p8m6TP0AC1RbvJIUPDHzerWGqG4vgaYG2ONXY46UQfsZ92C6P84HpQk/DNc2t
         TjbsSDK1uUVYhQQjq2SVzX4fxhv2rULkRZ1cOSXu7M1Uu8OGF6+dMOfzht+SxAUi9zS6
         U3p3skph96W/aaWHYM4twsja2vTx/wm4FJmSIlIQmqoVZDLziiTfFc3p8vECmCWqio+6
         8HKFcY1+FQrMcdwRbKCBATfougZjqCEIJFK65QCYqYRU3FDB7VET/jfIAzg0J6QjcAC2
         clC5oL0TeAZKTgwmJG3u/rBAFmf8uNdTY9VgDnFOizF2r9DMYsltTiEI1VsWODIeHxvW
         n8Ag==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J;
       spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com. [202.12.124.151])
        by gmr-mx.google.com with ESMTPS id 586e51a60fabf-2b28f4a3dacsi11155fac.5.2025.01.23.08.25.49
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 23 Jan 2025 08:25:49 -0800 (PST)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) client-ip=202.12.124.151;
Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44])
	by mailfout.stl.internal (Postfix) with ESMTP id C75291140152;
	Thu, 23 Jan 2025 11:25:48 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
  by phl-compute-04.internal (MEProxy); Thu, 23 Jan 2025 11:25:48 -0500
X-ME-Sender: <xms:jG2SZ1auE7my5mzIYEBahwE4o4TtPNfA8ArdZkp0z3UoKiugd27G8A>
    <xme:jG2SZ8aaQA-muKXXQQQ-bKDJJB4BlFNN28EEZ-6gNdCsThivXIL7h0WP7iNoQ8JDd
    rGp8YLqC2YlAOJkSnE>
X-ME-Received: <xmr:jG2SZ38ieOM8g6NnhSP2B0eErMG_YAMDHjzyg09dvJGOA03iV7YC8uxXEQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgvddufecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughr
    peffhffvvefukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefrvghtvghrucfvoh
    guugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvghrnhep
    geeiueffffffjeeuieduueefleekuedvtdduvedtvedufeejleetjeehvdehtdfgnecuff
    homhgrihhnpehkrhhufidrihhopdhgihhthhhusgdrtghomhdpghhoohhglhgvrdgtohhm
    pdgsihhttghoihhnthgrlhhkrdhorhhgpdgrrhgthhhivhgvrdhishdpthhrvgiiohhrrd
    hiohdpphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr
    rhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrghdpnhgspg
    hrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsghithgtohhi
    nhguvghvsehgohhoghhlvghgrhhouhhpshdrtghomhdprhgtphhtthhopehnohhthhhinh
    hgmhhutghhseifohhosghlihhnghdrohhrgh
X-ME-Proxy: <xmx:jG2SZzo2HP24vTKWsE2lcrDLmcmRLw3dNQ5uN5cnP3cSg62ZfKPcIw>
    <xmx:jG2SZwr3dqMLOMENAnLjWUd7Pqs3rQy637FbxsGMMarTc4-xniH4wA>
    <xmx:jG2SZ5THuGXA87OHq2GNq-XkhxQN6qKUKEtaFBY-5JwNicOQAFLwAA>
    <xmx:jG2SZ4qDCRpPaxNg7bAzf8Rl21DTLrHKNdF6uzZkjL9czh2CUwakEA>
    <xmx:jG2SZ1DyvOSDMj9GEqVHNieL4ZzdmDTGsI5Y5_CcgVJR2tRfhHdAo6ZL>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 23 Jan 2025 11:25:47 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
	id 55B879FC46; Thu, 23 Jan 2025 16:25:46 +0000 (UTC)
Date: Thu, 23 Jan 2025 16:25:46 +0000
From: Peter Todd <pete@petertodd.org>
To: Yuval Kogman <nothingmuch@woobling.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai)
 deanonymization attacks
Message-ID: <Z5JtilN2k7HwRRXt@petertodd.org>
References: <CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="4eHEatFitjb6mP2G"
Content-Disposition: inline
In-Reply-To: <CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com>
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J;       spf=pass
 (google.com: domain of pete@petertodd.org designates 202.12.124.151 as
 permitted sender) smtp.mailfrom=pete@petertodd.org
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 (/)


--4eHEatFitjb6mP2G
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 21, 2024 at 03:16:09PM +0100, Yuval Kogman wrote:

I've been reviewing Wasabi and other coinjoin implementations lately and
I believe that your focus on lite clients with regard to Wasabi is
incorrect. Let's go through the issues:


# Sybil Attacks In General

Let's get this out of the way first. As AdamISZ correctly noted in his
Jan 7th reply=C2=B9 to you, sybil attacks in general are impossible to
entirely prevent in any coinjoin protocol where participation is done
anonymously. It is always possible for an adversary to simply flood the
mechanism with coinjoin requests to the point where they are the only
counterparty.

What we can do is make sybil attacks costly. In general, Wasabi's
current usage with user-settable centralized coordinators does that
pretty well: typical coinjoin rounds on the most popular coordinator,
https://coinjoin.kruw.io, are transactions close to the standard size
limits, with hundreds of inputs and outputs, mixing millions of USD
dollars worth of BTC per round. A trivial sybil flood attacker would
have to spend a lot of money and hold a lot of coins to simulate that.


# Attacks via Failed Rounds

Secondly, there's a potential class of attacks via failed rounds;
attacks via failed rounds are potentially cheap/free attacks, as no
transaction fees are actually spent. A Wabisabi coordinator gets desired
inputs and outputs from clients, which would allow them to learn
something about which inputs are linked to each other, and which outputs
were desired by the owner of those inputs, if the coordinator
succesfully "sybil" attacks the client.

This class of attack might be interesting if Wasabi reused outputs after
rounds failed, in subsequent rounds. I have not verified whether or not
this is actually true; AdamISZ did confirm to me that JoinMarket does
*not* do this, resulting in large gaps between used outputs in typical
operation (it's normal for a high % of rounds to fail). This is an
implementation issue due to gap-limits in HD wallet implementations;
Silent Payment-like functionality may be a way around this problem.
Additionally, this class of attack would impact pay-in-coinjoin
functionality, where a payment address is added directly to a coinjoin.


# Attacks via "Successful" Rounds

If the round actually completes, the transaction fees must actually be
paid, and liquidity must be provided. So if the attacker wants to do a
cheaper attack than the "dumb" attack that is always possible, they must
find a way to get other participants to provide that liquidity and pay
those fees.

You keep bringing up lite clients, e.g. in your statement that:

	Unfortunately only full nodes can verify that a coin really is unspent.
	If a user has configured Wasabi to use a full node this is ideal but
	probably would not be the norm.
	-https://github.com/WalletWasabi/WalletWasabi/issues/5533

Your focus is mistaken. In fact, it's irrelevant whether or not a txin
in a proposed coinjoin round is spending a coin that exists or not. The
reason is there are two possible situations:

1) The coin is either spent, or never existed at all. The round will
   fail as the transaction is invalid, meaning we're actually dealing with
   a form of Attack via Failed Round. As described above, these aren't
   particularly interesting attacks.
=20
2) The coin is unspent, and the round succeeds. Whether or not a
   reduced-cost sybil was successful depends on round identity
   consistency.

Clients do *not* need to validate coins in coinjoin rounds. Whether or
not they're real is irrelevant, as the Bitcoin consensus itself
validates this for you.


## Consistency of Round Identity

As you mention, here we have a form of MITM attack, leveraged to perform
a sybil attack: if Alice and Bob are coinjoining at the same time, from
Alice's perspective, if the coordinator can pretend to be Bob, the
coordinator can run two simultaneous "rounds" that are actually creating
the same transactions. Thus the coordinator is re-using Bob's liquidity
and fees to sybil attack Alice. This type of sybil even works with N
participants: for each participant the coordinator can create a round
with N-1 other fake participants, MITM attacking each simultaneously.

Since Wasabi already has coin ownership proofs and distributes them, I
believe we can easily validate the round ID consistency of a coinjoin
transaction after it's fully signed and confirmed by simply validating
that the signatures on the inputs were in fact signed by the pubkeys of
the corresponding coin ownership and round ID proof. Wasabi already
evaluates the anonymity score of outputs. So performing this check would
simply mean that we're validating that the round was not sybilled, and
the anonymity score is valid.

The only question left for this technique is a cryptography one:

Is it possible to create an alternate pubkey p', that such that a valid
signature s signed by arbitrary pubkey p for message m, also validates
for p' for signature s and message m? I believe the answer is no for
schnorr. But I'm not a cryptography expert, and I may have missed
something.


# References

1) https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/oJTF8wqRDgAJ


> ### WabiSabi
>=20
> This affects Wasabi Wallet, and Ginger Wallet which is a fork of
> Wasabi. Trezor Suite was also affected, but has subsequently removed
> support for coinjoins[^18]. They too were made aware of various issues
> and chose to ignore them, despite contributing the limited (read:
> purely theater for privacy, only addressing hardware wallet specific
> theft scenario) ownership proof verification.
>=20
> Here the issue is more complex, but ultimately reduces to key
> consistency as well.
>=20
> In the protocol clients register their Bitcoin UTXOs independently. A
> valid input registration request includes a BIP-322 ownership proof,
> which commits to the so called *Round ID*. This in turn is a hash
> commitment to the parameters of the round, including the server's
> anonymous credential issuance parameters (analogous to a public key).
>=20
> The parameters are obtained by polling the server for information
> about active rounds. If inconsistent round IDs are given to clients,
> this effectively partitions them, allowing deanonymization.
>=20
> Although clients obtain the ownership proofs of other clients and
> seemingly verify them, BIP-322 proofs verification requires knowledge
> of the spent outputs `scriptPubKey` which light clients cannot obtain
> on their own. This public key is included alongside the ownership
> proofs, which makes their verification non-binding, the server can
> generate unrelated public keys, and create ownership proofs with those
> keys that commit to the per-client round IDs, which the client will
> accept as valid.
>=20
> This issue was described before the initial release[^7] but never
> addressed. Although subsequently ownership proofs were given to
> clients[^8], this change only addressed the use of ownership proofs to
> identify a wallet's own inputs in a stateless signing device, without
> addressing the consistency issues. Because the server provides the
> public key against which unknown inputs ownership proofs must be
> verified, that places them under adversarial control.
>=20
> Related issues and comments I have posted over the years:
>=20
> - unimplemented consistency check that does not depend on prevout also
> not implemented[^9]
> - no commitment to coordinator address in the round parameters[^10],
> although this was temporarily fixed the fix was reverted[^11]
> - additional missing fields in the round parameter commitments, and
> rationale addressing tagging attacks[^12]
> - initial description of blind signature based protocol, which
> predates my collaboration and design of the anonymous credential based
> protocol which also addresses this explicitly[^13]
>=20
> Finally, although not in scope I will also note that poor coin
> selection (bad randomization and de-randomization), improper
> randomization of input registration timing, and tor circuit management
> increase the probability of the success of such an attack, by making
> it easier to target specific users. Additional concerns exist for
> alternative clients due to use of JSON and HTTP in the protocol, in
> the C# implementation serialization by a 3rd party JSON library, which
> may canonicalize JSON differently (e.g. ordering of properties in JSON
> objects), etc. Additionally, although designed with coordination fees
> in mind, the anonymous credential mechanism did not enforce that
> coordination fees are fair or incentive compatible (nor can it with
> non-binding ownership proofs, though the main privacy concern there is
> the coordinator lying about the values of other clients' prevouts
> leading to poor amount decomposition), resulting in thefts of user
> funds[^14][^15], but this has now been removed[^16].
>=20
> Again a version of this with some preliminaries is also on github.[^17]
>=20
> [^7]: https://github.com/WalletWasabi/WalletWasabi/issues/5533
> [^8]: https://github.com/WalletWasabi/WalletWasabi/pull/8708
> [^9]: https://github.com/WalletWasabi/WalletWasabi/issues/6394#issuecomme=
nt-920225648
> [^10]: https://github.com/WalletWasabi/WalletWasabi/issues/5992
> [^11]: https://github.com/WalletWasabi/WalletWasabi/pull/8708/files#diff-=
04b849802b4adf5b34756a49b498f2ac97247cbb64424e5a69ee64c28a7033bcR120
> [^12]: https://github.com/WalletWasabi/WalletWasabi/issues/5439
> [^13]: https://gist.github.com/nothingmuch/61968fde675a596758bffd4c278ac0=
96
> [^14]: https://github.com/WalletWasabi/WalletWasabi/discussions/13249
> [^15]: https://bitcointalk.org/index.php?topic=3D5499439.msg64309927#msg6=
4309927
> [^16]: https://archive.is/xFRHO
> [^17]: https://gist.github.com/nothingmuch/4d717e12e451ff4ce43474972e41c6=
ba
> [^18]: https://blog.trezor.io/important-update-transitioning-from-coinjoi=
n-in-trezor-suite-9dfc63d2662f
>=20
> --=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/CAAQdECCdRVV%2B3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg%40mail.gmail.com.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--=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/=
Z5JtilN2k7HwRRXt%40petertodd.org.

--4eHEatFitjb6mP2G
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmeSbXQACgkQLly11TVR
LzfOAQ//YnMYgYylWQqhKLxg1khCjrwQc3yQ2Bi0/oQeCZZmoWrljYDh3Z5rVBq0
sfidCODGOE8v1J+TgbvI3wfRuRVgmsG7MCVyMYptINOnoKrnklOjmnzS8hVV5eyJ
46QgTbazMKXHOKn32FkfQduw+akNv8RqL6Lf5Qoy7S4P3RvzHT3eGTmP2LYQFKxE
UjYnCFrZ2e8L59jXeCvyn468vBnFc7CVKgAwmafV8AlhOaSArwAAJsFZQWQBpFcM
KXJT8aI8+QGRaqSY4nYdiB2/lFYz2Va/bhIPCNLpOkEHVNhW1cxxLBa5i4wJyYb5
QcjrEKc+itk0N/1IjCfOVYjGD6qM/VGBJgrFtSiichJSLOSykXJin9sLxrjeUDaZ
cpbSZTuaKI0ogmumUbyQcCrk+uroWt4LSmgHwIBltHeoaPhqMNfoZDNbfMkOMIVf
NLd8f4dWdXLgrYrprUstaCyav/BxdVkOSI6c2ge13Mn/5HuzSUerncHjFUpevpQU
MEy0j6t3wnaFomzvf53bxPdhSYSENPh28NT7hynIKwyEwdfrC4b25YirnSgWs8bO
8yJvpChnO8kg0VaR99jc16QnhSMXxjMx+2gFl3S9w6NH5diMFZN3bFhHQo+ggHYX
5lbrlzfKnhKEhu/z1LirragJPAT6rGcZjdbaDerhDmmHHaRNFzo=
=sUsB
-----END PGP SIGNATURE-----

--4eHEatFitjb6mP2G--