1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 747AFC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 29 Dec 2019 10:23:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 5E9A984489
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 29 Dec 2019 10:23:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id D0ldmgIaeUg7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 29 Dec 2019 10:23:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 8CC5A84415
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 29 Dec 2019 10:23:45 +0000 (UTC)
Date: Sun, 29 Dec 2019 10:23:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1577615023;
bh=pNNFp+629K8+W8wzEdcoAaVljFe4Tuo7JET7ZZVbhPE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=X+hl2/YgpM+ybcW0YZirmx0RmhkkT7MJJh5GDOrgxBuYaZ0crlyO0qz4IkIEPpiBX
uu3fOgJONl2QtUNKKIrmC5u4oUXeyokuSF9CaOHGbWhSEC+oyHUQjBlOrwZrGLS51W
l9yZRMxYUOGOL0VQfIrQeJXXjrn0MdAJg6yKkBCs=
To: Yuval Kogman <nothingmuch@woobling.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Ucl9pe26g2ECz-SRmXPV3WLxVR8PBOf0dnMR_aD8NwTqBNmq6e3a9hKJtwkYPJz7v_QUCxT_Y5X0w1VkvbiQZ6H3QJVcOtpUhNYTQ29rwFA=@protonmail.com>
In-Reply-To: <CAAQdECBqFKxAoZXCkWynN4wj5g8C9vzdhuEWk9b-BYqDW=us6g@mail.gmail.com>
References: <CAEPKjgdtgDbyLoj6FV+cjY1Djca_FBtd9Kt_eB4zWU+at=wfYQ@mail.gmail.com>
<CAAQdECBqFKxAoZXCkWynN4wj5g8C9vzdhuEWk9b-BYqDW=us6g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Dec 2019 10:23:47 -0000
Good morning Yuval,
> Additionally (though is a broader criticism of CoinJoin based privacy and=
not specific to unequal amounts, and in particular refers to ZmnSCPxj's as=
sertion of 0 linkability) I am very worried that perspectives that focus on=
linkability information revealed by a single coinjoin transaction in isola=
tion. This problem was alluded in the document, to but I don't see that it =
was addressed. Naively the post/pre mix transaction graph would seem to pre=
sent a computationally much harder problem when looking at the combinatoric=
s through the same lens, but reality it can also be used to place many cons=
traints on valid partitions/sub-transaction assignments for a single transa=
ction with equal amounts. The trivial example is post mix linking of output=
s, but there are many other ways to draw inferences or eliminate possible i=
nterpretations of a single transaction based on its wider context, which in=
turn may be used to attack other transactions.
Indeed, this is a problem still of equal-valued CoinJoin.
In theory the ZeroLink protocol fixes this by strongly constraining user be=
havior, but ZeroLink is not "purely" implemented in e.g. Wasabi: Wasabi sti=
ll allows spending pre- and post-mix coins in the same tx (ZeroLink disallo=
ws this) and any mix change should be considered as still linked to the inp=
uts (though could be unlinked from the equal-valued output), i.e. returned =
to pre-mix wallet.
> Finally, the proof as well as its applicability seems suspect to me, sinc=
e seems to involve trusting the server:
> "Since the distinct list [...] [is] kept on the server and not shared wit=
h the players"
> "The server knows the linkages of the commitments but does not participat=
e as a verifier "
> "If there is a problem [...] each component is assigned to another player=
at random for verification"
> these 3 statements together seems to suggest the server is trusted to not=
use sybils in order the compromise privacy by participating in the verific=
ation process?
Equal-valued CoinJoins fix this by using a Chaumian bank, which constrains =
value transfers to specific fixed amounts.
Since an equal-valued CoinJoin uses a single fixed amount anyway, it is not=
an additional restriction.
CashFusion cannot use the same technique without dropping into something ve=
ry much like an equal-valued CoinJoin.
Regards,
ZmnSCPxj
|
