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
|
Return-Path: <riccardo.casatta@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D650ACC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Oct 2019 11:00:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com
[209.85.222.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9915D89B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Oct 2019 11:00:39 +0000 (UTC)
Received: by mail-qk1-f181.google.com with SMTP id u184so12144596qkd.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Oct 2019 04:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=rG0A+Zpo6ELgI/pQUwZtqnZJPNWCs7wfxuZi5j+J0BY=;
b=U+ZwKP4k4DyoeInL7SqFOb3bBiFy9krE9JxME/bXG0eZlAEVRukC7ICsELlgliwqVb
i/CwhAg55EQy/QPHSFatis0tnDpqyR36WkWvLVdf4REHMxVnPmgPD7mKK6dK+JBgZR4T
PRiy30DE22NpU+u8bxDTMi5I71+VHPYWKOZoAA0Dcb6EExXU5qdwWBnFv+Mzc1rWmypB
7yW55fZzRf3dBORzbDkFeUCbTnSx8JsdFl6DK+mIutnbtle0W677eOvSf05rbDJmuUHH
csDG94R1RCoVKaexjOf+4ZbM3F01baiZ4wASPxW8zA2kFbGTEQmCo4UlmRWvQ/EkO/jo
Fv+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:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=rG0A+Zpo6ELgI/pQUwZtqnZJPNWCs7wfxuZi5j+J0BY=;
b=nO/C6BRlhaWPHm+QjeYz5iIX66+Xu7awNOe4llbyRMtmvSL2KqOEaIGFwYEXZdn0d9
S3ScH7SxixiWzH7CO8r3jHCIdk37K0/YUKSd3Czw2THNvNu7hv9KRql16qGTRUj/n+9P
GBqmlKj0DWkV/bzL29EBPxoXxnl+l3P7qqYrt4k2QbrbhM0waC8Hi3+nq9uWrKfh2pdu
jKubQqlV2stYleKGOjf9avnBoyet42Iu0kHfUKcrK0JS5ztwcAKyS4SzgcLRjGgxLVL1
KyRuoybEjciALrWNWRDkFhdQCzkHN4Z8Xws1oHjCXEIfurJxTyFrf7kffLbFA58T5KaP
YsJg==
X-Gm-Message-State: APjAAAW1uU5sCbJnr1zPmZKrnceiuQVfYmqfB4KWFqA9ZnRPDjB3zPrX
41tXRTkXamEqxcbcYMxAIl8eBhu5R47hgeY5piF8/Q==
X-Google-Smtp-Source: APXvYqxpVAy98b1GZ+89uCZKgRSEEkJdacLTsaCI/BiwU+hKIEIDqFDpVrOqXyq1TuGH2WiMuBEYZZFCExpr/FDjJB0=
X-Received: by 2002:a37:9a8a:: with SMTP id c132mr19142651qke.92.1571655638112;
Mon, 21 Oct 2019 04:00:38 -0700 (PDT)
MIME-Version: 1.0
References: <YwZ3vq20LFvpx-nKn1RJjcRHwYTAVCC0v0EyD0y6zVMlQtKXUFNAaEk_QE2dzYDU6z2eK0S0TDXRPfl1_y93RgDjdCGboOgjcERBTLUPHao=@protonmail.com>
<20191021000608.ajvzjxh6phtuhydp@ganymede>
In-Reply-To: <20191021000608.ajvzjxh6phtuhydp@ganymede>
From: Riccardo Casatta <riccardo.casatta@gmail.com>
Date: Mon, 21 Oct 2019 13:00:26 +0200
Message-ID: <CADabwBCnTj1_9M7oibhTj0JAj3O=i+ejHPZMDOUpyneJAuGGcw@mail.gmail.com>
To: "David A. Harding via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000004df6605956998d3"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 21 Oct 2019 15:13:22 +0000
Cc: SomberNight <somber.night@protonmail.com>
Subject: Re: [bitcoin-dev] Draft BIP for SNICKER
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: Mon, 21 Oct 2019 11:00:40 -0000
--00000000000004df6605956998d3
Content-Type: text/plain; charset="UTF-8"
The "Receiver" could immediately create a tx that spend the coinjoin
outputs to bip32 keys,
The hard part is that he had to delay the broadcast otherwise he loose
privacy
Il giorno lun 21 ott 2019 alle ore 02:08 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> ha scritto:
> On Sun, Oct 20, 2019 at 12:29:25AM +0000, SomberNight via bitcoin-dev
> wrote:
> > waxwing, ThomasV, and I recently had a discussion about implementing
> > SNICKER in Electrum; specifically the "Receiver" role.
>
> That'd be awesome!
>
> > As the referenced section [0] explains, the "Receiver" can restore
> > from seed, and assuming he knows he needs to do extra scanning steps
> > (e.g. via a seed version that signals SNICKER support), he can find
> > and regain access to his SNICKER outputs. However, to calculate `c` he
> > needs access to his private keys, as it is the ECDH of one of the
> > Receiver's pubkeys and one of the Proposer's pubkeys.
> >
> > This means the proposed scheme is fundamentally incompatible with
> > watch-only wallets.
> >
> > [0]
> https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys
>
> Your logic seems correct for the watching half of the wallet, but I
> think it's ok to consider requiring interaction with the cold wallet.
> Let's look at the recovery procedure from the SNICKER documentation
> that you kindly cited:
>
> 1. Derive all regular addresses normally (doable watch-only for
> wallets using public BIP32 derivation)
>
> 2. Find all transactions spending an output for each of those
> addresses. Determine whether the spend looks like a SNICKER
> coinjoin (e.g. "two equal-[value] outputs"). (doable watch-only)
>
> 3. "For each of those transactions, check, for each of the two equal
> sized outputs, whether one destination address can be regenerated
> from by taking c found in the method described above" (not doable
> watch only; requires private keys)
>
> I'd expect the set of candidate transactions produced in step #2 to be
> pretty small and probably with no false positives for users not
> participating in SNICKER coinjoins or doing lots of payment batching.
> That means, if any SNICKER candidates were found by a watch-only wallet,
> they could be compactly bundled up and the user could be encouraged to
> copy them to the corresponding cold wallet using the same means used for
> PSBTs (e.g. USB drive, QR codes, etc). You wouldn't even need the whole
> transactions, just the BIP32 index of the user's key, the pubkey of the
> suspected proposer, and a checksum of the resultant address.
>
> The cold wallet could then perform step #3 using its private keys and
> return a file/QRcode/whatever to the hot wallet telling it any shared
> secrets it found.
>
> This process may need to be repeated several times if an output created
> by one SNICKER round is spent in a subsequent SNICKER round. This can be
> addressed by simply refusing to participate in chains of SNICKER
> transactions or by refusing to participant in chains of SNICKERs more
> than n long (requring a maximum n rounds of recovery). It could also be
> addressed by the watching-only wallet looking ahead at the block chain a
> bit in order to grab SNICKER-like child and grandchild transactions of
> our SNICKER candidates and sending them also to the cold wallet for
> attempted shared secret recovery.
>
> 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 cold
> wallet anyway to sign the coinjoins.
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta>
--00000000000004df6605956998d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">The=
"Receiver" could immediately create a tx that spend the coinjoin=
outputs to bip32 keys,<br></div><div class=3D"gmail_default" style=3D"font=
-size:small">The hard part is that he had to delay the broadcast otherwise =
he loose privacy<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">Il giorno lun 21 ott 2019 alle ore 02:08 David A.=
Harding via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> ha scritto:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Oct 20, 2019 a=
t 12:29:25AM +0000, SomberNight via bitcoin-dev wrote:<br>
> waxwing, ThomasV, and I recently had a discussion about implementing<b=
r>
> SNICKER in Electrum; specifically the "Receiver" role. <br>
<br>
That'd be awesome!<br>
<br>
> As the referenced section [0] explains, the "Receiver" can r=
estore<br>
> from seed, and assuming he knows he needs to do extra scanning steps<b=
r>
> (e.g. via a seed version that signals SNICKER support), he can find<br=
>
> and regain access to his SNICKER outputs. However, to calculate `c` he=
<br>
> needs access to his private keys, as it is the ECDH of one of the<br>
> Receiver's pubkeys and one of the Proposer's pubkeys.<br>
> <br>
> This means the proposed scheme is fundamentally incompatible with<br>
> watch-only wallets.<br>
> <br>
> [0] <a href=3D"https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156=
e2cf25d79#Storage_of_Keys" rel=3D"noreferrer" target=3D"_blank">https://gis=
t.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys</a><b=
r>
<br>
Your logic seems correct for the watching half of the wallet, but I<br>
think it's ok to consider requiring interaction with the cold wallet.<b=
r>
Let's look at the recovery procedure from the SNICKER documentation<br>
that you kindly cited:<br>
<br>
=C2=A0 =C2=A0 1. Derive all regular addresses normally (doable watch-only f=
or<br>
=C2=A0 =C2=A0 wallets using public BIP32 derivation)<br>
<br>
=C2=A0 =C2=A0 2. Find all transactions spending an output for each of those=
<br>
=C2=A0 =C2=A0 addresses.=C2=A0 Determine whether the spend looks like a SNI=
CKER<br>
=C2=A0 =C2=A0 coinjoin (e.g. "two equal-[value] outputs").=C2=A0 =
(doable watch-only)<br>
<br>
=C2=A0 =C2=A0 3. "For each of those transactions, check, for each of t=
he two equal<br>
=C2=A0 =C2=A0 sized outputs, whether one destination address can be regener=
ated<br>
=C2=A0 =C2=A0 from by taking c found in the method described above" (n=
ot doable<br>
=C2=A0 =C2=A0 watch only; requires private keys)<br>
<br>
I'd expect the set of candidate transactions produced in step #2 to be<=
br>
pretty small and probably with no false positives for users not<br>
participating in SNICKER coinjoins or doing lots of payment batching.<br>
That means, if any SNICKER candidates were found by a watch-only wallet,<br=
>
they could be compactly bundled up and the user could be encouraged to<br>
copy them to the corresponding cold wallet using the same means used for<br=
>
PSBTs (e.g. USB drive, QR codes, etc).=C2=A0 You wouldn't even need the=
whole<br>
transactions, just the BIP32 index of the user's key, the pubkey of the=
<br>
suspected proposer, and a checksum of the resultant address.<br>
<br>
The cold wallet could then perform step #3 using its private keys and<br>
return a file/QRcode/whatever to the hot wallet telling it any shared<br>
secrets it found.<br>
<br>
This process may need to be repeated several times if an output created<br>
by one SNICKER round is spent in a subsequent SNICKER round.=C2=A0 This can=
be<br>
addressed by simply refusing to participate in chains of SNICKER<br>
transactions or by refusing to participant in chains of SNICKERs more<br>
than n long (requring a maximum n rounds of recovery).=C2=A0 It could also =
be<br>
addressed by the watching-only wallet looking ahead at the block chain a<br=
>
bit in order to grab SNICKER-like child and grandchild transactions of<br>
our SNICKER candidates and sending them also to the cold wallet for<br>
attempted shared secret recovery.<br>
<br>
The SNICKER recovery process is, of course, only required for wallet<br>
recovery and not normal wallet use, so I don't think a small amount of<=
br>
round-trip communication between the hot wallet and the cold wallet is<br>
too much to ask---especially since anyone using SNICKER with a<br>
watching-only wallet must be regularly interacting with their cold<br>
wallet anyway to sign the coinjoins.<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature"><div dir=3D"ltr">Riccardo Casatta - <a href=3D"https://twit=
ter.com/RCasatta" target=3D"_blank">@RCasatta</a></div></div>
--00000000000004df6605956998d3--
|
