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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9AF2EF37
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Oct 2019 13:21:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5384C896
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Oct 2019 13:21:07 +0000 (UTC)
Date: Tue, 22 Oct 2019 13:21:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1571750465;
bh=GDmhqn5K32xmGIJe2M3WBlcVVxI30DKCUGdlMZVGXG4=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=uDtZbn6LpDxBrASISc51mAj3AF6X0KzSIkWe2z4weDZNymuEczL6OOkr5ER8Ap9nR
hX8m4RmyYWyJFBvJvhzMHrzaFuQ7jPm+d2dr4zwz74H8xtOgw1A3sTvf2kELwwJHAk
WylF4i/gtuIystQhNMzbM4ClPQYQ8QvqwiqlVrrI=
To: SomberNight <somber.night@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <mq_HOhcWf2T7ik9Em3nb5VCePi5cV17Wf_c8qS5zWwXh0vnJVzBO_q6Nl8RQBJysBOhZC2rjAw3hbq2tHIoEyTKE8QQaJgF9LpgpcP0Nl8g=@protonmail.com>
In-Reply-To: <clOIQUf5e2vT3KqKplQwrS5MgB8ptPDSQWkpOMGoAE3rS90i7y-8mNRmcecfVJwiYePhNYAfFlBYsOKqvavm4yVI-zEfo8pnG6AY_fiyMXs=@protonmail.com>
References: <YwZ3vq20LFvpx-nKn1RJjcRHwYTAVCC0v0EyD0y6zVMlQtKXUFNAaEk_QE2dzYDU6z2eK0S0TDXRPfl1_y93RgDjdCGboOgjcERBTLUPHao=@protonmail.com>
<20191021000608.ajvzjxh6phtuhydp@ganymede>
<clOIQUf5e2vT3KqKplQwrS5MgB8ptPDSQWkpOMGoAE3rS90i7y-8mNRmcecfVJwiYePhNYAfFlBYsOKqvavm4yVI-zEfo8pnG6AY_fiyMXs=@protonmail.com>
Feedback-ID: bXDrzvuRufYtwlP51LbX1U1HVhop5RoBgHwub9Drp1-jSqeBk7WF1gtL3tVf_bUUZyA1LgUYiqtef7oP8A2trw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Tue, 22 Oct 2019 13:28:32 +0000
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: Tue, 22 Oct 2019 13:21:09 -0000
Just to chime in on these points:
My discussions with ghost43 and ThomasV led me to the same conclusion, at l=
east in general, for the whole watch-only issue:
It's necessary that the key tweak (`c` as per draft BIP) be known by Propos=
er (because has to add it to transaction before signing) and Receiver (to c=
heck ownership), but must not be known by anyone else (else Coinjoin functi=
on fails), hence it can't be publically derivable in any way but must requi=
re information secret to the two parties. This can be a pure random sent al=
ong with the encrypted proposal (the original concept), or based on such, o=
r implicit via ECDH (arubi's suggestion, now in the draft, requiring each p=
arty to access their own secret key). So I reached the same conclusion: the=
classic watch-only use case of monitoring a wallet in real time with no pr=
ivkey 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 SNI=
CKER transactions arrive.
For (2) it's interesting to observe that the tweak `c` is not a money-contr=
olling secret; it's only a privacy-controlling secret. If you imagined two =
wallets, one hot and one cold, with the second tracking the first but havin=
g a lower security requirement because cold, then the `c` values could be s=
ent along from the hot to the cold, as they are created, without changing t=
he cold's security model as they are not money-controlling private keys. Th=
ey should still be encrypted of course, but that's largely a technical deta=
il, if they were exposed it would only break the effect of the coinjoin out=
puts being indistinguishable.
For (1) the above does not apply; for there, we don't have anyone telling u=
s 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 describe things t=
hat 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 Ligh=
tning; importing keys is generally non-trivial; one can always sweep non-st=
andard keys back into the HD tree, but clearly that is not really a solutio=
n in general; one can mark out wallets/seeds of this type as distinct; not =
all wallets need to have watch-only (phone wallets? small wallets? lower se=
curity?) one can prioritise spends of these coins. Etc.
Some more general comments:
Note Elichai's comment on the draft (repeated here for local convenience: h=
ttps://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 Pro=
poser who should after all be assumed to be an attacker (except, I emphasis=
ed that PSBT parsing could be sensitive on this point); I hope it's clear t=
o everyone that the construction Q =3D P + cG is only controllable by the o=
wner 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 Me=
ssage =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-d=
ev@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 cold
> wallet anyway to sign the coinjoins.
>
> What you described only considers the "initial setup" of a watch-only wal=
let. There are many usecases for watch-only wallets. There doesn't even nec=
essarily need to be any offline-signing involved. For example, consider a u=
ser who has a hot wallet on their laptop with xprv; and wants to watch thei=
r 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, a=
nd 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
