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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D95319F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Nov 2017 10:38:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29B7FF1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Nov 2017 10:38:35 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id 21so10742381uas.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Nov 2017 02:38:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=0Ed4sAhseX25fplXEPXxsAXtkCR7u2emJq85CVu7e9I=;
b=X1oGGqowlvYLKhXC/A45m6nTjhlo0QB9IVRi2+GvgpwkywJE7B6XoSmpjB4d2rOsh0
mEThS2rEUHxCddL7pYWvvMp7DKgRRnf5RIP+4buMBQasAl1xmWA0yAbPOWdua7+UJKvN
26gDuxhJilKIZPispk3lzuAt2zKt9mgM/03Nlk5btdL2lC3AWWHXVIaeXf/gPC3XIYI3
JlE7WQ/p2AJvA1Ie6JAQF23/vUY1n2FeAdg0yhfgUkRzx3EGCgWTdXSDcQjiIpZZMB7L
Y922N4kL3dREHZP6j7yTF/RPcxeC+j1GGLs6ZE1womb/diGytor8wkW4OebRGDBwp37n
YN+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=0Ed4sAhseX25fplXEPXxsAXtkCR7u2emJq85CVu7e9I=;
b=Z+oyzoQBVMG2A4ZqUM92zKtyOz9iNrkb9wjI0DRxdMKCda1f5Ylh1DbW3CG46a5HDc
t/VNSfP90gWYWn3kVxVS1lT79tLqBRzku0QQ1GXhBiv9Xwbco++bMHbmjtzEKDYZz6dI
/2OnxEgAifoDuxSvPRJsd+hOXGW3LvtZq57fe2e2CNrlLCV/ocSvZ9/V3eyUp/YV1bi1
mkAzfwVVEkxoFOYZus9vOEnxxnoj/WMKxbc1SwDMeghfxlEoCSkfiYtPFptp3O3e/wXy
DZDVLWEKiUc+Iss7K9h7StJBG1GGqIwqbwjtdCKJf4mmW10cCMhid9p855Sxy8YeGjQ4
5BNQ==
X-Gm-Message-State: AJaThX6npNuD9ZYhrZMhd7SoExtFNmdm3soufx6RHAQb8Q6zclzPoXYk
Ia2IzC0lqxdy4M8+uXmKYI8cVu42PeduY0Mi+0T6Kw==
X-Google-Smtp-Source: AGs4zMafobRYYpEe9DZbAVw3QICop2AMkDNvj2NyrmNy7n9Uuctd6lGFUiQISFCLXa6GyaeRUc6F0LKoIvbOR8vOIyg=
X-Received: by 10.176.16.67 with SMTP id g3mr10214005uab.109.1510655914157;
Tue, 14 Nov 2017 02:38:34 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.85.148 with HTTP; Tue, 14 Nov 2017 02:38:33 -0800 (PST)
In-Reply-To: <20171114091123.GA29286@savin.petertodd.org>
References: <CAAS2fgQ0Cb2B=Ye2TnpfQqP4=kpZCxMWRXYB0CcFa71sQJaGuw@mail.gmail.com>
<20171114091123.GA29286@savin.petertodd.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 14 Nov 2017 10:38:33 +0000
X-Google-Sender-Auth: xWycOGpNoMKZA3O-xznWKjY1q-o
Message-ID: <CAAS2fgQVJU659NsX054YTTB1MCDWtSk9PXJo5+EgrBRRG+VDsw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Updates on Confidential Transactions efficiency
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 14 Nov 2017 10:38:36 -0000
On Tue, Nov 14, 2017 at 9:11 AM, Peter Todd <pete@petertodd.org> wrote:
> I _strongly_ disagree with this statement and urge you to remove it from the
> paper.
I very strongly disagree with your strong disagreement.
> The worst-case risk of undetected inflation leading to the destruction of a
> currency is an easily quantified risk: at worst any given participant loses
> whatever they have invested in that currency. While unfortunate, this isn't a
> unique or unexpected risk: cryptocurrencies regularly lose 50% - or even 90% -
> of their value due to fickle markets alone. But cryptocurrency owners shrug
> these risks off. After all, it's just money, and diversification is an easy way
> to mitigate that risk.
>
> But a privacy break? For many users _that_ threatens their very freedom,
> something that's difficult to even put a price on.
Its important that people know and understand what properties a system has.
Perhaps one distinction you miss is that perfectly hiding systems
don't even exist in practice: I would take a bet that no software on
your system that you can use with other people actually implements a
perfectly hiding protocol (much less find on most other people's
system system :)).
In the case of practical use with CT perfect hiding is destroyed by
scalability-- the obvious construction is a stealth address like one
where a DH public key is in the address and that is used to scan for
your payments against a nonce pubkey in the transactions. The
existence of that mechanism destroys perfect hiding. No scheme that
can be scanned using an asymmetric key is going to provide perfect
hiding.
Now, perhaps what you'd like is a system which is not perfect hiding
but where the hiding rests on less "risky" assumptions. That is
something that can plausibly be constructed, but it's not itself
incompatible with unconditional soundness.
As referenced in the paper, there is also the possibility of having a
your cake and eating it too-- switch commitments for example allow
having computational-hiding-depending-on-the-hardness-of-inverting-hashes
(which I would argue is functionally as good as perfect hiding, esp
since hiding is ultimately limited by the asymmetric crypto used for
discovery) and yet it retains an option to upgrade or block spending
via unsound mechanisms in the event of a crypto break.
> Furthermore, the risk of inflation is a risk that's easily avoided:
Sounds like you are assuming that you know when there is a problem, if
you do then the switch commitments scheme works and doesn't require
any selling of anything. Selling also has the problem that everyone
would want to do it at once if there was a concern; this would not
have good effects. :) Without switch commitments though, you are just
hosed. And you cannot have something like switch commitments without
abandoning perfect hiding ( though you get hiding which is good enough
(tm), as mentioned above).
On Tue, Nov 14, 2017 at 10:07 AM, Peter Todd <pete@petertodd.org> wrote:
> Re: the unprunable accumulators, that doesn't need to be an inherent property
> of Zcash/Monero style systems.
>
> It'd be quite feasible to use accumulator epochs and either make unspent coins
> in a previous epoch unspendable after some expiry time is reached - allowing
Miners to reduce coin supply, enhancing the value of their own
holdings, by simply not letting near-expiry ones get spent...
(This can be partially mediated by constructing proofs to hide if a
coins in near expiration or not.)
> or make use of a merkelized key-value scheme with transaction provided proofs to shift the costs of
> maintaining the accumulator to wallets.
Yes, that they can do-- though with the trade-offs inherent in that.
It is worse than what you were imagining in the Bitcoin case because
you cannot use one or two time-ordered trees, the spent coins list
needs search-insertion; so maintaining it over time is harder. :( The
single time ordered tree trick doesn't work because you can't mutate
the entries without blowing anonymity.
I think it's still fair to say that ring-in and tree-in approaches
(monero, and zcash) are fundamentally less scalable than
CT+valueshuffle, but more private-- though given observations of Zcash
behavior perhaps not that much more private. With the right smart
tricks the scalablity loss might be more inconvenient than fatal, but
they're still a loss even if they're one that makes for a good
tradeoff.
As an aside, you shouldn't see Monero as entirely distinct now that
we're talking about a framework which is fully general: Extending
this to a traceable 1 of N input for monero is simple-- and will add
size log() in the number of ring inputs with good constant factors.
One could also store inputs in a hash tree, and then have a
bulletproof that verified membership in the tree. This would provide
tree-in style transactions with proofs that grow with the log() of the
size of the tree (and a spent coins accumulator); the challenge there
would be choosing a hash function that had a compact representation in
the arithmetic circuit so that the constant factors aren't terrible.
Effectively that's what bulletproofs does: It takes a general scheme
for ZKP of arbitrary computation, which could implement a range proof
by opening the commitments (e.g. a circuit for EC point scalar
multiply) and checking the value, and optimizes it to handle the
commitments more directly. If you're free to choose the hash function
there may be a way to make a hash tree check ultra efficient inside
the proof, in which case this work could implement a tree-in scheme
like zcash-- but with larger proofs and slower verification in
exchange for much better crypto assumptions and no trusted setup.
This is part of what I meant by it opening up "many other interesting
applications".
But as above, I think that the interactive-sparse-in (CJ) has its own
attractiveness, even though it is not the strongest for privacy.
|
