summaryrefslogtreecommitdiff
path: root/88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d
blob: af04e55f235781c6346fee82012b44ab2e937db9 (plain)
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
317
318
319
Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CB332C01
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Aug 2017 20:14:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com [74.125.83.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB5014FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Aug 2017 20:14:19 +0000 (UTC)
Received: by mail-pg0-f54.google.com with SMTP id v77so32192680pgb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Aug 2017 13:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=g0fj4Mk8FEdTD/Li0xwDxME/aiIz+YXidNCsr4cWmWQ=;
	b=X63CbLqzc8wBJ5wIrto5pBPMfE9W2cnDex8mJHiib/qwlxeyH8CoPWnvJ9+SdDuhra
	nVIJr2m+he6RKn3J9Nn6GMo/AUGZmgGIFnFleTUabxgyrKwLPgp0FmlnTdIlmPnEOnu1
	DLIhn3KGR0uSaNgPTXb9Hn0t3lvVsfH/iqRd4dgPZedrpaMIkYGyO/XSbUHQJWBMTYVt
	Wo9LqJdey3TdErUp3kpQlZAekLts9NCHR8CkcM2jprqSut1y3UxElvk76E1Gx2m0GCXD
	GlCA+JKihPT3m/klXlUOSvZiHjnQFU6owul0uBflu6eszFMNY5OUilAcnPoH7ZQVPJzQ
	/zNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=g0fj4Mk8FEdTD/Li0xwDxME/aiIz+YXidNCsr4cWmWQ=;
	b=K1VPh5jrb/WxNJhW2u+CH42XsbmUtbSKbj2MMRBaNwjmz1Mkht2yJUm6vGgb0XwZRR
	+HYpyRXHkxAn6X9w/tHaIKnZ+33VeaOPbD4wVyYyVmElYqi+YHs35J9Q/oabeNmtaFHk
	Wqo8F7PVjquMk0GdxJOOgnnuUEmEP9yJz4bBOanl9bQCJc0F4ZVawFu1HyN4FGsCgK4C
	7L36kSOUQ0MFaSMr0RHVDaRz5rRIiT0/MifErvJEMEWz+F4sioiVcyT8f+T8+WolmUEQ
	KYF+tpdzDvdVBBmFLo0JLdyiY3PoSMGtwHIzFo0S3W1HEfDJE3MtKfQ0yf6UUF5slLDI
	XVuA==
X-Gm-Message-State: AHYfb5iKLGBOBqrHph/WT5XWkvJgfJgnB61lkAjptPoIvZPqyYMJDNkj
	77GnLh0pNi1Y5vEs+7KxB7tDl3dQuA==
X-Received: by 10.98.70.86 with SMTP id t83mr9443270pfa.219.1502309659157;
	Wed, 09 Aug 2017 13:14:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.166.168 with HTTP; Wed, 9 Aug 2017 13:14:18 -0700 (PDT)
In-Reply-To: <CAJJsNHvDbPpo+31bN0eYtgARnZe_ZeoVz7=bm9HuAjUM0ztKBA@mail.gmail.com>
References: <CAJJsNHsiAH3Wc_Fp-8f=5EBg8-jNH8rtEW5+u+PEC7JU+SdCGQ@mail.gmail.com>
	<CAJJsNHv_iPNnGgqqogoxGEk+5ipoELfPAnMM0obWUpTjWRZJRQ@mail.gmail.com>
	<CAJJsNHvKR+ieYaFYw_KeCmJjWTzBYH9mSSFwtOdoyYB-kA+fLQ@mail.gmail.com>
	<CAJJsNHuz17GQkKWsKc0sOJfueEyyJkPM0ErbSNB_A=9Qq9tgTQ@mail.gmail.com>
	<CAJJsNHsdcYc7WiLuBSYPfoOvjG-v10zFL1d7_ROxx1HYx-nzHA@mail.gmail.com>
	<CAJJsNHuMa9WoWm0_MZ+dDVRM6UxhOA7eNWqNX=NAVw6V7Nb0jg@mail.gmail.com>
	<CAJJsNHsn=x-EzAWvRH171uM_8hmX9=_zYrn6yyn_mMP3DQGbbw@mail.gmail.com>
	<CAJJsNHvXpeMgxLZZ6JDFX859xnYC30Xvs24=G8-pmE+GUk9prw@mail.gmail.com>
	<CAJJsNHu+Rg7-mHY7mBVL6trKAbTfyq_44KjiQjRkU99_DUyCiQ@mail.gmail.com>
	<CAJJsNHueWeocmYN7tQZ111wi6GyAf81OBpR0gaqJaq6N0RokSQ@mail.gmail.com>
	<CAJJsNHvaeOdhia9bd1b-FTobUvYPsdryRo1U7fPdf=J6Xng1Rw@mail.gmail.com>
	<CAJJsNHuWf42Pzz39oH1F+NHxPoeMdoXqT8-5F8B5OLye1o8sFQ@mail.gmail.com>
	<CAJJsNHum5CVA7HOL26__WjFAQV09mAxfvDJ3o1Yu3BYNydzdvw@mail.gmail.com>
	<CAJJsNHs_aDmuqKpetceM+t_+jQLs8m0hFgtvhCJVvNLBrn3VjQ@mail.gmail.com>
	<CAJJsNHsT0VBufwkr4Lk-yRndeKDhchrp5g-UDv-vhcyjpi3-LA@mail.gmail.com>
	<CAJJsNHt46qBoihBBojt4Fu7S7Ryrqi-1HpXGiX4_nVMDQBq1oQ@mail.gmail.com>
	<CAJJsNHtCDCaW3ZtnNutL9q-PY4b5+eS-zcyfgT1B23gKH+127A@mail.gmail.com>
	<CAJJsNHuU3NXGjZ+afUQ_Ct_3y5V7JgZQzemc9SQUGmGjrm8wfQ@mail.gmail.com>
	<CAJJsNHt08PbYvtcVbCPw383-93r-NuCV_UPjGZ+moHime4dzFw@mail.gmail.com>
	<CAJJsNHvtJ3eUNgpe8apLDoC_UOmk+0ezLiTXkhdG2tndTx=WBA@mail.gmail.com>
	<CAJJsNHu+8+42R0jMfLbNZ7K8c0kQR3Tex+xiPH6WE+w_f+ORPQ@mail.gmail.com>
	<CAJJsNHubV--c5xJQrrF6F5K5gQ2gexy3x-7pL_Gn7Oe6TpiMbw@mail.gmail.com>
	<CAJJsNHvEPWSdquKrOt5kGRFFmLJ3yq2YfxEuQUC9upmKYV4oeg@mail.gmail.com>
	<CAJJsNHsMBz06oo-miAkqUC4VenYq1+o08pi=fgDsnaq9B_+KSA@mail.gmail.com>
	<CAJJsNHun0bf-TKxOr-WVJ1Tj3zt40OZOZAtzxRhD_+ise_+7=g@mail.gmail.com>
	<CAJJsNHvurUUkysWzjbxcXhdaUbL-CRPiBBABFd2HuFD14wZLkQ@mail.gmail.com>
	<CAJJsNHsib5VRs4R1N6C6ZhynAGhJ+QxW3d2LbzojEFnwddyyhw@mail.gmail.com>
	<CAJJsNHt01LuXqD+V=++6fp_VyW7TZ_1OzrsxZ7brBiqUKHcdng@mail.gmail.com>
	<CAJJsNHuZ_iMdeV0jZ618jO7osvUk97uV9Wae9NA_dgRQT=E5uQ@mail.gmail.com>
	<CAJJsNHtZ8bEZ-5zfpjzhoxfzaOM1RuZvRx6J+Pcr=r0=zZd=Kg@mail.gmail.com>
	<CAJJsNHspUanL7Y1E9RB_4G54Fs3RUy1uqUw8aUq3XYY6os_5ww@mail.gmail.com>
	<CAJJsNHtumDA8js_kaagwDHxLy9iF7UXwb5n9yX5cLvwNDDEMaw@mail.gmail.com>
	<CAJJsNHss2bW0DqYkvf5W4CMG3gaWFcT4oqXyzT4y93FveR6k4A@mail.gmail.com>
	<CAJJsNHuHA_rksFEip9r=hKuHoM9Bag2AmFYr=2miJKzOWJC5dQ@mail.gmail.com>
	<CAJJsNHv1QtpDvw_CZKhqryCxD21jtL+MQbZgqG-0HxzBbsnvPw@mail.gmail.com>
	<CAJJsNHtNMQGiJwarobHKBau7o_hEnSMKSznKkbfa8y4e4BUA8Q@mail.gmail.com>
	<CAJJsNHsX9Za=+8LYTK8mnq8XtuMrL03U2LAXHy15qv+XEKupZA@mail.gmail.com>
	<CAJJsNHuyty=i6Mxu_sreVBkqmgDKtp3050=Hh1qy8Hfs8yV2sw@mail.gmail.com>
	<CAJJsNHvNRzd0ZCv3QX9cR=JV8eUHF0z2QWdx9CK1v42iz2fOyA@mail.gmail.com>
	<CAJJsNHsYjFj-g1RBoRMoTrfjLStCQ8SQrE7ZcM569yW0mxb1qQ@mail.gmail.com>
	<CAJJsNHvVEydafdqx7ZwG9XmdNLZzbewVpAMfnvS=ZXNzV1fQYQ@mail.gmail.com>
	<CAJJsNHtEqzEg83k_s4Kg0YiJ3tWfCPOTPmnH0D-YiKZ6K5oGGg@mail.gmail.com>
	<CAJJsNHt2WydZewhrH5XZ-mpUMGBYvfke1H6F2cORpORv=LxShQ@mail.gmail.com>
	<CAJJsNHsCQXkp2uDTMTRJ=2ZVTcUXEPCPNusncACFtGoov5cOzw@mail.gmail.com>
	<CAJJsNHusmafTVS3xTyT5hR3ZjLkQ99A9qQK33e05BRdTF7+xhQ@mail.gmail.com>
	<CAJJsNHsp8oW=C-yzO5qiF9imZf-5EO+pYUJU6yHZz1wF=nevUA@mail.gmail.com>
	<CAJJsNHvOMxE2sBa4TKaazMsRH4OJaN=eS0JDRO81=J1OzGLkcg@mail.gmail.com>
	<CAJJsNHu3EZx9c2x99gwSEUNBCEa3SirteUx8+MqWcU_ShjLDRA@mail.gmail.com>
	<CAJJsNHsBYgmTmGeqUnvjnomO10m_TXjgt5xS8rROcV2aF=PPsQ@mail.gmail.com>
	<CAJJsNHsKSE9ftorgZ4J7YLwz5rMpYq-7WpEtk61JEtxJfneKVQ@mail.gmail.com>
	<CAJJsNHuTY+ckfvujru2K4vsOkfHyp1kYMJQAF0rmSeHhv3HdaA@mail.gmail.com>
	<CAJJsNHuYfMWGjkw1_RPA5-a6p_EVsv3b4gussi9y9Mb8+WsR_A@mail.gmail.com>
	<CAJJsNHv=cEnxg=yTCiDjWRedpBLuXmAyk-mGgQbHMDxFqoiiBw@mail.gmail.com>
	<CAJJsNHs90da2u+ufLcVoqyYQ_pkAr55=gL_ZY0mAGCoDmyqMbQ@mail.gmail.com>
	<CAJJsNHtni20bBUjLd_KOLnVxnZ4_AdDumLCkWbiU4v-cgXfJcA@mail.gmail.com>
	<CAJJsNHtVQ_hSQho2yd_4n8g+sQ5mCZjrG-SALcm1Vrbb3_1oVw@mail.gmail.com>
	<CAJJsNHus+SGAfh6SR9uY_VjgSiSsqtsH0=V-ecM8pm=whwSp0g@mail.gmail.com>
	<CAJJsNHvruYORGrd--nQayYW28k=F-A9PiP9O25w_1pvR2ABvcw@mail.gmail.com>
	<CAJJsNHsTYta-e0S_VZNMHNrEYnfy57U1W_bbzvkS3gQ=qVt75g@mail.gmail.com>
	<CAJJsNHv+TyGj=Mg3t2DS5YAW5WMdjckjFZA5KTO=JDtHB9iNCg@mail.gmail.com>
	<CAJJsNHukqjvTv-2G0jM8D6c2Bmt0o_uW6cd=GXvJHOzmSRg+BA@mail.gmail.com>
	<CAJJsNHv8mnT_GUcHmZy=6=_k1PxBSpfMSTtrz9UbERzhVwSbgw@mail.gmail.com>
	<CAJJsNHtb8Zed+5jZKx3oBNP7EMV-OPbuJD9mPjryRuroM=2bnA@mail.gmail.com>
	<CAJJsNHsWjUeCUp9jHwzEMMuN9jT2CNocpLyJRJKzDvY5Q_VAaQ@mail.gmail.com>
	<CAJJsNHuLfeB_oP+98jteLyr_q=_pdWkJP1+h4fgUBoeG3shBXQ@mail.gmail.com>
	<CAJJsNHuM-k1-MKHw-TcP5RFJz7bwg=YuLvjXKzunYcUK7wYhjg@mail.gmail.com>
	<CAJJsNHvEttaWfk9FQXA34WskxqU5sTyzvK_a56voWVOb7vtbcQ@mail.gmail.com>
	<CAJJsNHukHECFiMj2PFKOMSQmkT1f8Y=N20_9bx2p_3n0ahJKmQ@mail.gmail.com>
	<CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@mail.gmail.com>
	<CAJJsNHvDbPpo+31bN0eYtgARnZe_ZeoVz7=bm9HuAjUM0ztKBA@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
Date: Wed, 9 Aug 2017 14:14:18 -0600
Message-ID: <CANN4kmfXy-Lkuai-VyPOG_EQ3ybV4t-3GTixHLzSanKJHe419Q@mail.gmail.com>
To: Colin Lacina <notdatoneguy@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0b82a493ac43055657b94e"
X-Mailman-Approved-At: Wed, 09 Aug 2017 20:15:31 +0000
Subject: Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets
 Using P2SH for Recovery Options
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: Wed, 09 Aug 2017 20:14:19 -0000

--94eb2c0b82a493ac43055657b94e
Content-Type: text/plain; charset="UTF-8"

Colin,

1) This is a good start for a BIP, but it's missing details. For example,
the nonce is encrypted by the server. What key is it encrypted with?
Clarifying ambiguities like this can sometimes reveal weaknesses that you
wouldn't otherwise think of.

2) What kind of recovery questions are asked? If it's something like "What
was the name of your first pet?" then what prevents the server from
stealing the wallet by trying a dictionary of the most common pet names? Is
there a mitigation to this, besides picking cryptographically secure
identifiers for my pets?

--Nick

On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I believe I have come up with a structure that allows for trustless use of
> hybrid wallets that would allow for someone to use a hybrid wallet without
> having to trust it while still allowing for emergency recovery of funds in
> the case of a lost wallet. It would run off of this TX script:
>
> IF
>      1 <clientRecoveryPubKey> <serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
> ELSE
>      2 <userWalletPubKey> <serverWalletPubKey> 2 CHECKMULTISIG
> ENDIF
>
> A typical transaction using this would involve a user signing a TX with
> their userWalletPrivKey, authenticating with the server, possibly with 2FA
> using a phone or something like Authy or Google Authenticator. After
> authentication, the server signs with their serverWalletPrivKey.
>
> In case the server goes rogue and starts refusing to sign, the user can
> use their userRecoveryPrivKey to send the funds anywhere they choose.
> Because if this, the userRecoveryPrivKey is best suited to cold wallet
> storage.
>
> In the more likely event that the user forgets their password and/or
> looses access to their userWalletPrivKey as well as loses their recovery
> key, they rely on the serverRecoveryPrivKey.
>
> When the user first sets up their wallet, they answer some basic identity
> information, set up a recovery password, and/or set up recovery questions
> and answers. This information is explicitly NOT sent to serve with the
> exception of recovery questions (although the answers remain with the user,
> never seeing the server). What is sent to the server is it's 256 bit hash
> used to identify the recovery wallet. The server then creates a 1025 bit
> nonce, encrypts it, stores it, and transmits it to the user's client.
>
> Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
>
> Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
> SHA512 on the combination of the identity questions and answers, the
> recovery password (if used), the recovery questions and answers, and the
> nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
>
> Finally, the already encrypted key is encrypted again for transmission to
> the server. The server decrypts it, then rencrypts it for long term storage.
>
> When the user needs to resort to using this option, they 256 bit hash
> their information to build their recovery identifier. The server may,
> optionally, request e-mail and or SMS confirmation that user is actually
> attempting the recovery.
>
> Next, the server decrypts the saved nonce, as well as the first layer of
> encryption on the serverRecoveryPrivKey, then encrypts both for
> transmission to the user's client. Then the client removes the transmission
> encryption, calculates the 512 bit hash that was used to originally encrypt
> the serverRecoveryPrivKey by using the provided information and the nonce.
>
> After all of that the user can decrypt the airbitzServerRecoveryPrivKey
> and use it to send a transaction anywhere they choose.
>
> I was thinking this may make a good informational BIP but would like
> feedback.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c0b82a493ac43055657b94e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Colin,</div><div><br></div><div>1) This is a good sta=
rt for a BIP, but it&#39;s missing details. For example, the nonce is encry=
pted by the server. What key is it encrypted with? Clarifying ambiguities l=
ike this can sometimes reveal weaknesses that you wouldn&#39;t otherwise th=
ink of.</div><div><br></div><div>2) What kind of recovery questions are ask=
ed? If it&#39;s something like &quot;What was the name of your first pet?&q=
uot; then what prevents the server from stealing the wallet by trying a dic=
tionary of the most common pet names? Is there a mitigation to this, beside=
s picking cryptographically secure identifiers for my pets?</div><div><br><=
/div><div>--Nick</div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I believe I have c=
ome up with a structure that allows for trustless use of hybrid wallets tha=
t would allow for someone to use a hybrid wallet without having to trust it=
 while still allowing for emergency recovery of funds in the case of a lost=
 wallet. It would run off of this TX script:<div dir=3D"auto"><br></div><di=
v dir=3D"auto">IF</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A01 &lt;clientRe=
coveryPubKey&gt;=C2=A0<span style=3D"font-family:sans-serif">&lt;<wbr>serve=
rRecoveryPubKey&gt; 2 CHECKMULTISIGVERIFY</span></div><div dir=3D"auto"><sp=
an style=3D"font-family:sans-serif">ELSE</span></div><div dir=3D"auto"><spa=
n style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A02 &lt;userWalletPubK=
ey&gt; &lt;serverWalletPubKey&gt; 2 CHECKMULTISIG</span></div><div dir=3D"a=
uto"><span style=3D"font-family:sans-serif">ENDIF</span></div><div dir=3D"a=
uto"><span style=3D"font-family:sans-serif"><br></span></div><div dir=3D"au=
to"><span style=3D"font-family:sans-serif">A typical transaction using this=
 would involve a user signing a TX with their userWalletPrivKey, authentica=
ting with the server, possibly with 2FA using a phone or something like Aut=
hy or Google Authenticator. After authentication, the server signs with the=
ir serverWalletPrivKey.</span></div><div dir=3D"auto"><span style=3D"font-f=
amily:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-fa=
mily:sans-serif">In case the server goes rogue and starts refusing to sign,=
 the user can use their userRecoveryPrivKey to send the funds anywhere they=
 choose. Because if this, the userRecoveryPrivKey is best suited to cold wa=
llet storage.</span></div><div dir=3D"auto"><span style=3D"font-family:sans=
-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-family:sans-=
serif">In the more likely event that the user forgets their password=C2=A0<=
/span><span style=3D"font-family:sans-serif">and/or looses access to their =
userWalletPrivKey=C2=A0</span><span style=3D"font-family:sans-serif">as wel=
l as loses their recovery key, they rely on the serverRecoveryPrivKey.</spa=
n></div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span=
></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">When the us=
er first sets up their wallet, they answer some basic identity information,=
 set up a recovery password, and/or set up recovery questions and answers. =
This information is explicitly NOT sent to serve with the exception of reco=
very questions (although the answers remain with the user, never seeing the=
 server). What is sent to the server is it&#39;s 256 bit hash used to ident=
ify the recovery wallet. The server then creates a 1025 bit nonce, encrypts=
 it, stores it, and transmits it to the user&#39;s client.</span></div><div=
 dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div =
dir=3D"auto"><span style=3D"font-family:sans-serif">Meanwhile, the user&#39=
;s wallet client generates the serverRecoveryPrivKey.</span></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div dir=
=3D"auto"><span style=3D"font-family:sans-serif">Once the client has both t=
he serverRecoveryPrivKey, and the nonce, it uses SHA512 on the combination =
of the identity questions and answers, the recovery password (if used), the=
 recovery questions and answers, and the nonce. It uses the resulting hash =
to encrypt the serverRecoveryPrivKey.</span></div><div dir=3D"auto"><span s=
tyle=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span st=
yle=3D"font-family:sans-serif">Finally, the already encrypted key is encryp=
ted again for transmission to the server. The server decrypts it, then renc=
rypts it for long term storage.</span></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif">When the user needs to resort to using this opt=
ion, they 256 bit hash their information to build their recovery identifier=
. The server may, optionally, request e-mail and or SMS confirmation that u=
ser is actually attempting the recovery.</span></div><div dir=3D"auto"><spa=
n style=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span=
 style=3D"font-family:sans-serif">Next, the server decrypts the saved nonce=
, as well as the first layer of encryption on the serverRecoveryPrivKey, th=
en encrypts both for transmission to the user&#39;s client. Then the client=
 removes the transmission encryption, calculates the 512 bit hash that was =
used to originally encrypt the serverRecoveryPrivKey by using the provided =
information and the nonce.</span></div><div dir=3D"auto"><span style=3D"fon=
t-family:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font=
-family:sans-serif">After all of that the user can decrypt the airbitzServe=
rRecoveryPrivKey and use it to send a transaction anywhere they choose.</sp=
an></div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></spa=
n></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I was thin=
king this may make a good informational BIP but would like feedback.</span>=
</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c0b82a493ac43055657b94e--