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
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
|
Return-Path: <AdamISZ@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4C098C087F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Nov 2019 12:43:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 3AE1985B94
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Nov 2019 12:43:38 +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 0V_BQAn_FWYP
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Nov 2019 12:43:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
[185.70.40.131])
by fraxinus.osuosl.org (Postfix) with ESMTPS id AEADD85A74
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Nov 2019 12:43:35 +0000 (UTC)
Date: Sat, 23 Nov 2019 12:43:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1574513013;
bh=tHFTB3lhnabyqxOc84UzfrRxRZwanPq/WdTxcqYl0n4=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=qkUI2359thPRp6GEAQ/xECCKXdl9nfaaQ1eC3NvNxFDQExF4RJq0Q/WJuhPnde900
kEhdThvujIc1HZoCWhKRoi9j8m4yBTSwmABiI22S3BzcC/R5qiErDNZd3EF70I6nY7
oIlmatxeb2+4skr7k3ihHlqWyEuu6sHmZHJcXzQg=
To: popo <PoliceTerror@dyne.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <_KQ9Rhe6FCZjxJX7inBrWnwtHG0K-aiK7LBf7xhlyrbUr_zNC_A3Act3MiOJ1wl9S7mFwIlVl29H6tmP6SLWk-S5zUzsFOVexKiVGUC_1i4=@protonmail.com>
In-Reply-To: <adad1616-a8c2-9d76-4a14-2160e37fc8b2@dyne.org>
References: <YwZ3vq20LFvpx-nKn1RJjcRHwYTAVCC0v0EyD0y6zVMlQtKXUFNAaEk_QE2dzYDU6z2eK0S0TDXRPfl1_y93RgDjdCGboOgjcERBTLUPHao=@protonmail.com>
<20191021000608.ajvzjxh6phtuhydp@ganymede>
<clOIQUf5e2vT3KqKplQwrS5MgB8ptPDSQWkpOMGoAE3rS90i7y-8mNRmcecfVJwiYePhNYAfFlBYsOKqvavm4yVI-zEfo8pnG6AY_fiyMXs=@protonmail.com>
<mq_HOhcWf2T7ik9Em3nb5VCePi5cV17Wf_c8qS5zWwXh0vnJVzBO_q6Nl8RQBJysBOhZC2rjAw3hbq2tHIoEyTKE8QQaJgF9LpgpcP0Nl8g=@protonmail.com>
<CADabwBAAstxX4ezm3B2sGcDWOcrJUNJ+wfPMY6ArWd4qSAkrLg@mail.gmail.com>
<B6OyNJfSL9qQgAr7ktQzWvLW_Q3t5b9zHKb4CRd2sH_VdpW5ZsRUSNhG133JA64ZQ-TjjDZHlf8sBMhduzLpptTQo71iwhLoDqMx9GPPlVc=@protonmail.com>
<adad1616-a8c2-9d76-4a14-2160e37fc8b2@dyne.org>
Feedback-ID: bXDrzvuRufYtwlP51LbX1U1HVhop5RoBgHwub9Drp1-jSqeBk7WF1gtL3tVf_bUUZyA1LgUYiqtef7oP8A2trw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 23 Nov 2019 13:17:19 +0000
Subject: Re: [bitcoin-dev] Draft BIP for SNICKER
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: Sat, 23 Nov 2019 12:43:38 -0000
Two party mixes can be useful in the context of a very large number of them=
.
There is no pretence that doing one such, or even doing several such, gives=
any privacy *guarantees*.
However, if it can be arranged that such 'mixes' occur frequently across a =
broad spectrum of wallets - and the claim is that that is possible precisel=
y because at least one of the two participants needs to do *absolutely noth=
ing at all* for the join to happen - then the degradation of blockchain ana=
lysis could be pretty severe.
What's described here therefore is essentially an attempt to go to the othe=
r far extreme from 'rigidly controlled and coordinated large mix sets' to '=
ultra loosely coupled almost zero coordination mixing', trading off size in=
one step for convenience/low effort/even zero effort mixing. Part of that =
may (or may not) involve Proposers being specialised entities, and it's onl=
y the Receiver side that's zero effort.
It should be noted that the two extremes are not incompatible; if one is va=
luable, it doesn't mean the other isn't.
But what I think you can deduce: a proposal to do SNICKER that just involve=
d a very small set of users would not be much use (still not zero, though);=
the tradeoffs have been made having in mind the idea of more usage, especi=
ally more *broad* usage.
Answering about 2 party joins in more general terms:
Any such coinjoin, no matter its pattern, will break the common input owner=
ship heuristic. If there are equal sized outputs of the same scriptpubkey t=
ype (as is proposed) then that delinking effect is of considerable value al=
so.
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, November 22, 2019 2:57 PM, popo via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
> Hi, AFAIK snicker is limited to 2 party mixes for the foreseeable future.
> What makes this a useful anonymity system for cryptocurrency/Bitcoin?
>
> Thanks
>
> On 11/22/19 3:02 PM, AdamISZ via bitcoin-dev wrote:
>
> > Hi Riccardo,
> > Apologies for not answering before, this slipped my mind.
> > Clearly what you propose is possible, and adding the proposer's own
> > signed transaction is a nice touch to make it more privacy-viable.
> > For now my inclination is not to add this complexity, especially becaus=
e
> > of the cost implication.
> > I'd note though that your idea about adding in second-stage transaction=
s
> > aligns with the CoinJoinXT idea (or perhaps, just the segwit idea!).
> > Proposers could send sequences of transactions with various patterns,
> > including backouts and promises, but it would clearly be way more
> > complicated than what we're considering right now.
> > Regards,
> > Adam/waxwing
> > Sent with ProtonMail https://protonmail.com Secure Email.
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90
> > On Wednesday, November 6, 2019 4:52 PM, Riccardo Casatta via bitcoin-de=
v
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> >
> > > Hello Adam,
> > > are you sure you can't tackle the watch-only issue?
> > > What if the proposer create the coinjoin-tx, plus another tx
> > > (encrypted with the shared secret) which is a 1 input-1 output (1to1)
> > > tx which spend his output to another of his key.
> > > At this point when the receiver accept the proposal tx he could creat=
e
> > > other tx 1to1 which are spending his tweaked output to pure bip32
> > > derived key, he than broadcast together the coinjoin tx and for every
> > > output of the coinjoin tx one other tx which is a 1to1 tx.
> > > Notes:
> > >
> > > - We are obviously spending more fee because there are more txs
> > > involved but the receiver ends up having only bip32 derived outpu=
ts.
> > >
> > > - The receiver must create the 1to1 tx or the receiver lose privacy=
by
> > > being the only one to create 1to1 tx
> > >
> > > - a good strategy could be to let the coinjoin tx have a very low f=
ee,
> > > while the 1to1 tx an higher one so there is less risk that only t=
he
> > > coinjoin gets mined
> > >
> > > - Whit this spending strategy, the wallet initial scan does not nee=
d
> > > to be modified
> > >
> > >
> > > Il giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoin-dev
> > > <bitcoin-dev@lists.linuxfoundation.org
> > > mailto:bitcoin-dev@lists.linuxfoundation.org> ha scritto:
> > >
> > > Just to chime in on these points:
> > >
> > > My discussions with ghost43 and ThomasV led me to the same
> > > conclusion, at least in general, for the whole watch-only issue:
> > >
> > > It's necessary that the key tweak (`c` as per draft BIP) be known
> > > by Proposer (because has to add it to transaction before signing)
> > > and Receiver (to check ownership), but must not be known by anyon=
e
> > > else (else Coinjoin function fails), hence it can't be publically
> > > derivable in any way but must require information secret to the
> > > two parties. This can be a pure random sent along with the
> > > encrypted proposal (the original concept), or based on such, or
> > > implicit via ECDH (arubi's suggestion, now in the draft, requirin=
g
> > > each party to access their own secret key). So I reached the same
> > > conclusion: the classic watch-only use case of monitoring a walle=
t
> > > in real time with no privkey access is incompatible with this.
> > >
> > > It's worth mentioning a nuance, however: distinguish two
> > > requirements: (1) to recover from zero information and (2) to
> > > monitor in real time as new SNICKER transactions arrive.
> > >
> > > For (2) it's interesting to observe that the tweak `c` is not a
> > > money-controlling secret; it's only a privacy-controlling secret.
> > > If you imagined two wallets, one hot and one cold, with the secon=
d
> > > tracking the first but having a lower security requirement becaus=
e
> > > cold, then the `c` values could be sent along from the hot to the
> > > cold, as they are created, without changing the cold's security
> > > model as they are not money-controlling private keys. They should
> > > still be encrypted of course, but that's largely a technical
> > > detail, if they were exposed it would only break the effect of th=
e
> > > coinjoin outputs being indistinguishable.
> > >
> > > For (1) the above does not apply; for there, we don't have anyone
> > > telling us what `c` values to look for, we have to somehow
> > > rederive, and to do that we need key access, so it reverts to the
> > > discussion above about whether it might be possible to interact
> > > with the cold wallet 'manually' so to speak.
> > >
> > > To be clear, I don't think either of the above paragraphs describ=
e
> > > things that are particularly likely to be implemented, but the
> > > hot/cold monitoring is at least feasible, if there were enough
> > > desire for it.
> > >
> > > At the higher level, how important is this? I guess it just
> > > depends; there are similar problems (not identical, and perhaps
> > > more addressable?) in Lightning; importing keys is generally
> > > non-trivial; one can always sweep non-standard keys back into the
> > > HD tree, but clearly that is not really a solution in general; on=
e
> > > can mark out wallets/seeds of this type as distinct; not all
> > > wallets need to have watch-only (phone wallets? small wallets?
> > > lower security?) one can prioritise spends of these coins. Etc.
> > >
> > > Some more general comments:
> > >
> > > Note Elichai's comment on the draft (repeated here for local
> > > convenience:
> > > https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#=
gistcomment-3014924)
> > > about AES-GCM vs AES-CBC, any thoughts?
> > >
> > > I didn't discuss the security of the construction for a Receiver
> > > from a Proposer who should after all be assumed to be an attacker
> > > (except, I emphasised that PSBT parsing could be sensitive on thi=
s
> > > point); I hope it's clear to everyone that the construction Q =3D=
P
> > > + cG is only controllable by the owner of the discrete log of P
> > > (trivial reduction: if an attacker who knows c, can find the
> > > private key q of Q, he can derive the private key p of P as q - c=
,
> > > thus he is an ECDLP cracker).
> > >
> > > Thanks for all the comments so far, it's been very useful.
> > >
> > > AdamISZ/waxwing/Adam Gibson
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90
> > > On Monday, October 21, 2019 4:04 PM, SomberNight via bitcoin-dev
> > > <bitcoin-dev@lists.linuxfoundation.org
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> > >
> > > > > The SNICKER recovery process is, of course, only required for
> > > wallet
> > > >
> > > > recovery and not normal wallet use, so I don't think a small
> > > amount of
> > > > round-trip communication between the hot wallet and the cold
> > > wallet is
> > > > too much to ask---especially since anyone using SNICKER with a
> > > > watching-only wallet must be regularly interacting with their c=
old
> > > > wallet anyway to sign the coinjoins.
> > > >
> > > > What you described only considers the "initial setup" of a
> > > watch-only wallet. There are many usecases for watch-only wallets=
.
> > > There doesn't even necessarily need to be any offline-signing
> > > involved. For example, consider a user who has a hot wallet on
> > > their laptop with xprv; and wants to watch their addresses using
> > > an xpub from their mobile. Or consider giving an xpub to an
> > > accountant. Or giving an xpub to your Electrum Personal Server
> > > (which is how it works).
> > > >
> > > > Note that all these usecases require "on-going" discovery of
> > > addresses, and so they would break.
> > > >
> > > > ghost43
> > > >
> > > > (ps: Apologies Dave for the double-email; forgot to cc list
> > > originally)
> > > >
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > >
> > > --
> > > Riccardo Casatta - @RCasatta https://twitter.com/RCasatta
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
