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
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 10FB2C077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 02:11:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id E368F20468
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 02:11:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 7CPgk3QCnkh5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 02:11:52 +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 silver.osuosl.org (Postfix) with ESMTPS id 3494920440
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jan 2020 02:11:52 +0000 (UTC)
Date: Thu, 16 Jan 2020 02:11:44 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1579140709;
bh=+stejLYyKzemA1gxFDpsa11snIoRG5MqaHbigem6DJA=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=YMhx4RnE6Rsi4GZQYdA+waB9BQawwugrQ7/eXmFZoPYCJ5ArFBaGBDqbZzYb3Tp0T
C22D/BZ1hum0NdGVjTzFoD3nsZXJPWygPGLE0q2InA1avfrwPvrXXoTEiwM99zQHgo
5j5vT4jGdkRVpxIsh+DCnj1UyuCmF7lXu0QGijSQ=
To: Max Hillebrand <max@towardsliberty.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <T410nnBIHG8Gr2T8ir9OLa9e2SPi2EagjGntUByw-u1ELuJGU7Hh5cGHoBRlYJKbaXXbchECb-a-1HXHrQlx7wGoN1YeNocpXlnkiveddkc=@protonmail.com>
In-Reply-To: <96dc101e-30ba-9833-7ba0-41eda910d3cc@towardsliberty.com>
References: <96dc101e-30ba-9833-7ba0-41eda910d3cc@towardsliberty.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] ***UNCHECKED*** Wormhole: Sending and receiving
bitcoin anonymously
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: Thu, 16 Jan 2020 02:11:55 -0000
Good morning Max,
It seems similar very closely to TumbleBit, at least in the overall protoco=
l.
A cursory read does not reveal any direct problems with it.
Regards,
ZmnSCPxj
> Hello all!
>
> May I propose you this protocol which seemingly provides a great level
> of privacy for both the sender and receiver of bitcoin. This was
> initially posted to the Wasabi WalletGitHub, and after thoroughcontemplat=
ion and minor tweaks, I would now like to request your
> feedback on the conceptual design and possible implementation.
>
> Cheers
> Max
>
> Wormhole
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Abstract
>
> ---------
>
> A protocol to transfer bitcoin, without the receiver gaining knowledge
> of the input of the sender, and without the sender gaining knowledge of
> the output of the receiver, while simultaneously generating equal value
> CoinJoin outputs with anonymity set.
>
> Introduction
>
> -------------
>
> This is achieved by minor changes to theZeroLink CoinJoin protocol, utili=
zinga centralized coordinator who cannot steal, and cannot spy. Schnorr
> blind signatures are used to obfuscate the link between inputs and equal
> value outputs throughout the ceremony. The coordinator does not gain
> knowledge that Wormhole is used.
>
> Protocol
>
> ---------
>
> - Alice A [with tor identity A1 and A2] has a 5.5 bitcoin UTXO
> - A sends 1 bitcoin to Bob B [with tor identity B1 and B2]
> - Wasabi server W coordinates the zero link CoinJoin:
> =C2=A0=C2=A0=C2=A0 -- Equal value denominations are 1, 2, 4, 8, 16, 3=
2 bitcoin
> =C2=A0=C2=A0=C2=A0 -- Anonymity set for each denomination is 100
> =C2=A0=C2=A0=C2=A0 -- Wormhole protocol is opt-in for some unknown nu=
mber of peers
>
>
> ### Input Registration
>
> - A generates an input proof of the 5.5 bitcoin UTXO
> - A generates one `blindedOutput` with 4 bitcoin, and one
> `changeAddress` with 0.5 bitcoin
>
> - B generates one `blindedOutput` with 1 bitcoin & he sends this
> to A
>
> - A1 sends all of the above to W
> - W verifies
> =C2=A0=C2=A0=C2=A0 -- `maxInputsPerRegistraion` not reached
> =C2=A0=C2=A0=C2=A0 -- `maxInputPerTx` not reached
> =C2=A0=C2=A0=C2=A0 -- `blindedOutput` never registered
> =C2=A0=C2=A0=C2=A0 -- each input
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- not already registered=
for this round
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- UTXO not banned
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- proof
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- unspent
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- if coinbase, confirmat=
ions > 100
>
>
> --- must be SegWit v0 [maybe also v1] bech32
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- is from unconfirmed CoinJo=
in tx
>
> - W generates `uniqueID`
> - W signs all `blindedOutput`
> - W sends `uniqueID` & `signedBlindedOutput` to A1
>
> ### Connection Confirmation
>
> - Starts when `timeSinceLastRound > maxWaitPeriod` OR
>
> `registeredInputs > requiredInputs`
>
> - A abandons if confirmation is refused
> - A1 sends `uniqueID` W
> - W verifies `uniqueID`, and calculates `roundHash =3D hash of all regi=
stered inputs`
> - W sends `roundHash` to A1 and B1
>
> ### Output Registration
>
> - Starts when `confirmedUniquelds =3D=3D registeredInputs` OR `timeout =
&& confirmedUniquelds >=3D requiredInputs`
>
> - A sends `signedBlindedOuput_B` to B
>
> - Both A and B unblind the `signedBlindedOutput`
>
> - Both A2 and B2 send `output` & `signature` & `roundHash`
> DIRECTLY to W - they do NOT send to each other
>
> - W verifies `roundHash` & `signature` & `Output`
>
>
> ### Signing
>
> - Starts when `outputs =3D=3D registeredInputs` OR `timeout` [go signin=
g,
> even if there are missing outputs to identify them and ban them as th=
ey
> won't sign]
>
> - W builds CoinJoin transaction `CJTX` and sends to A1 and B1
> and all other peers
>
> - A and B verify `roundHash` [by calculating hash of all `txInputs`]
> - B verifies that his output is included & signs a commitment
> message m where he acknowledges that it is included & sends m to A
>
> - A verifies that her input and her outputs are included & verifies
> B signature of m [assumption that Bob provides a correct address, as
> with any transaction] & signs `CJTX`
>
> - A1 sends `uniqueID` & `signature, inputIndex` to W - A does
> NOT send this to B
>
> - W verifies `uniqueID` & each signature against
> `inputs[uniqueID][index]`
>
>
> ### Broadcast TX
>
> - Starts when `signatures =3D=3D registeredInputs`
> - W broadcasts signed transaction to the Bitcoin peer-to-peer network
>
>
> Result
>
> -------
>
> - A has one 4 bitcoin UTXO with 100 anonset & one 0.5 bitcoin
> UTXO with 1 anonset
>
> - B has one 1 bitcoin UTXO with 100 anonset
> - W knows the input and change of A & W does not know who
> controls which equal value output & W does not know that B has no inp=
uts
>
> - A does not know the output of B, there are 99 possible coins.
> - B does not know the input and outputs of A, there are 100+
> possible coins.
>
>
> Communication
>
> --------------
>
> This is an interactive protocol with several rounds of communication,
> thus all A & B & W need to be online. The communication between
> A and B can be done on any suitably private channel, including but
> not limited to tor, QR codes, SD cards, or carrier pigeon. The
> communication between A / B & W will be the same as used for the
> regular zero link implementation, most likely tor.
>
> Privacy
>
> --------
>
> The equal value zero link outputs from A and B have the anonymity
> set of the total number of equal value zero link outputs in the same
> transaction. Wormhole breaks the assumption that zero link is a
> consolidation within the same wallet [`Input Alice =3D Output Alice + Fee=
`], in a way that neither A nor B can spy on each other. W does
> not know if any peer is using Wormhole, none or one or all peers
> might use it.
>
> Questions
>
> ----------
>
> I am not sure what information is broadcasted from W to all peers in
> the round, and if Bob can get this information without revealing that he
> is the receiver of a Wormhole transaction [he has no input proof]. What
> information can be send from W to B directly will determine the
> trust level of A passing honest messages.
>
> Wormhole might be used in conjunction with Pay toEndpoint orKnapsack
> so that A can send a specific amount to B, with part being the equal
> value zero link output, and part the P2EP change, or Knapsack
> sub-transaction.
>
> Atomic coinswapswith Schnorr adaptor signatures might be integrated, so A=
input in
> `CJTX1` "pays" B output in `CJTX2`, but this might require B to know
> the signature [and thus the input] of A.
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------
>
> This email was signed with my PGP key E900 5F66 A86B B816 BD7D 967EBEDC D=
95C 42AC3C57Please verify it on my website,
> github and on the bottom
> right corner of my videos.
|