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
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
|
Return-Path: <adam.back@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id F399EC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 13:54:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id E296B86BA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 13:54:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Yt+StbSqRpWN
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 13:54:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com
[209.85.208.180])
by whitealder.osuosl.org (Postfix) with ESMTPS id 0B82A86B90
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 13:54:34 +0000 (UTC)
Received: by mail-lj1-f180.google.com with SMTP id w1so2532754ljh.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 06:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:reply-to:from:date:message-id
:subject:to:cc:content-transfer-encoding;
bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=;
b=UTczVHqywLLxp2gzShjwnccvOyKm4g2xgvF06PEoaBt48q4vvFHOShuuuVuf6D4ZQg
TlcVdmpA69mI8t73Yk/KWr/f2nHUWiQFb4kjPBqo0Zwj41xzXxA0mgGUGsloYMPnvpiA
8+TKRv9tZe6JIJhg5RCrWXinpwRYJVH7Ei6YYcW9AIoMnielQ/SMzzBNXxZMqjGUsep0
/9jLJIWXzN/0fWQlWtZncfok9FRlSEx+hGT/5WuEgdmQK2wMrivGEhUGMgshQwTOVN8G
eQdF7kvAsMEh/hB3AWm0YrpiZ/rpmF913mIPZOAB+cHHb1RGH3vLNY8ynBQ/By4JycJ3
JG/Q==
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:reply-to
:from:date:message-id:subject:to:cc:content-transfer-encoding;
bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=;
b=pEaAK+5OioIidpffIFG26lT+5QTMwttzNntaoSp2TIxaJNgY458M6Ob5S1HxWZiwRk
gFsrGe1cf7iiDAk5x3TCuORcM16on9tUjmucqBnjeeoIJN2hZPIP4VKgKBW99uUnDG5+
gFvg1ONJzJBLqljDB3pRHUAa+97zva0Kg0QJh2M/h0ID9XyvIhPo7LVO29mfyi1tCqR2
Tfc9vdTF39AWL7p4BR2wvYn752t474mpyrPFLeNGlcSPKd/8q9R4C6JBYE+GswKXRMmF
WFy/5Gg3wuS53DXV7HdfwNjSoR4f8s7quD4QU3mylZ6W2kP3iSYNY//UsvuSzqypovyt
5CfA==
X-Gm-Message-State: AGi0PuYsXSa0ra/X7NmHEyT7bXik/UbbZ9qhKRcgQ2y/pC3EH9+kicpi
aAv14HUk15GxtVh0kQbKY+XWcb5vZD/QOhr2Qmo=
X-Google-Smtp-Source: APiQypI1q0zHPthRKTUJvdBUtWCsmztWzjHbNwA6ed8bdvbiCv7EwWlnyz2YWhjKOjW06UnduRyJpnZD5YtEulN9J+I=
X-Received: by 2002:a2e:b0c2:: with SMTP id g2mr2140324ljl.102.1585144471841;
Wed, 25 Mar 2020 06:54:31 -0700 (PDT)
MIME-Version: 1.0
References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
<S90SB9DcluBjzhnWrbT1Urh61XgVcn6ynEU7EGsfR-UhGGMxPOXMuJdwM0BPtdAcIaL22B4zR0Pooe4Yaoi0zBPFnnwQ4WSSpL7FoW4OOBA=@protonmail.com>
<c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de>
In-Reply-To: <c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de>
Reply-To: adam@cypherspace.org
From: Adam Back <adam.back@gmail.com>
Date: Wed, 25 Mar 2020 14:54:18 +0100
Message-ID: <CALqxMTH4+WWKDzLh-6gC5GcaHvSMJjY9S8HNy-DwNgefdpuyUA@mail.gmail.com>
To: Tim Ruffing <crypto@timruffing.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
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: Wed, 25 Mar 2020 13:54:36 -0000
I think the point is to use this proposed extension/standard for a
kind of "seed management" function, set it up on an offline device (an
always offline laptop, or a modified hardware wallet) where you put
the master seed. And then you use this as a kind of seed manager and
transcript the seeds for different sub-wallets into the respective
wallets as BIP39 mnemonics.
So I do not think it needs any changes from existing wallet authors,
as the interaction point is a bip 39 seed, which they mostly know how
to use. Indeed if you were to modify an existing wallet to accept the
master seed from seed management scheme and derive the seed it needs
on each wallet, then that would create a weakest link in the chain
risk - if that wallet was insecure, or compromised then all other
derived seeds would be also and you want independence for each wallet.
I do think that this use case is a practical problem for people
managing multiple seeds for various wallets in a bitcoin business
setting or even power users - you lose the single backup design,
because it's too cumbersome to create fresh backups for each of
multiple wallets, especially distributed , fireproof cryptosteel etc
backups and so in practice for multi wallet scenarios probably they
are not all full backed up or not backed up as robustly (not as
geo-redundant, fireproof, secret-shared etc).
Adam
On Tue, 24 Mar 2020 at 09:32, Tim Ruffing via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I think your proposal is simply to use BIP32 for all derivations and
> the observation that you can work with derived keys with the
> corresponding suffixes of the path. I believe that this is a good idea.
>
> But I don't think that simply writing a standard will help. It's just
> one step. If all your wallets support incompatible formats, we should
> work on fixing this because that's the root of the issue. Otherwise you
> end up converting keys back and forth manually (as Chris pointed out),
> and this can't be the goal.
>
> But then you need to reach out to wallet devs explicitly and get them
> involved in creating the standard. Otherwise they won't use it. That's
> a hard process, and it's even harder to make sure that the resulting
> proposal isn't way too complex because everyone brings their special
> case to the table.
>
> Tim
>
> On Sun, 2020-03-22 at 11:58 +0000, Ethan Kosakovsky via bitcoin-dev
> wrote:
> > I have completely revised the wording of this proposal I hope to be
> > clearer in explaining the motivation and methodology.
> >
> > https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d=
6
> >
> > Ethan
> >
> > =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 Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > I would like to present a proposal for discussion and peer review.
> > > It aims to solve the problem of "too many seeds and too many
> > > backups" due to the many reasons stipulated in the proposal text.
> > >
> > > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4=
f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-fro=
m-bip32.mediawiki
> > >
> > > <pre>
> > > BIP:
> > > Title: Deterministic Entropy From BIP32 Keychains
> > > Author: Ethan Kosakovsky ethankosakovsky@protonmail.com
> > > Comments-Summary: No comments yet.
> > > Comments-URI:
> > > Status: Proposed
> > > Type: Standards Track
> > > Created: 2020-03-20
> > > License: BSD-2-Clause
> > > OPL
> > > </pre>
> > >
> > > =3D=3DAbstract=3D=3D
> > >
> > > This proposal provides a way to derive entropy from a HD keychain
> > > path in order to deterministically derive the initial entropy used
> > > to create keychain mnemonics and seeds.
> > >
> > > =3D=3DMotivation=3D=3D
> > >
> > > BIP32 uses some initial entropy as a seed to deterministically
> > > derive a BIP32 root for hierarchical deterministic keychains. BIP39
> > > introduced a method of encoding initial entropy into a mnemonic
> > > phrase which is used as input to a one way hash function in order
> > > to deterministically derive a BIP32 seed. The motivation behind
> > > mnemonic phrases was to make it easier for humans to backup and
> > > store offline. There are also other variations of this theme.
> > >
> > > The initial motivation of BIP32 was to make handling of large
> > > numbers of private keys easier to manage and backup, since you only
> > > need one BIP32 seed to cover all possible keys in the keychain. In
> > > practice however, due to various wallet implementations and
> > > security models, the average user may be faced with the need to
> > > handle an ever growing number of seeds/mnemonics. This is due to
> > > incompatible wallet standards, hardware wallets (HWW), seed formats
> > > and standards, as well as, the need to used a mix of hot and cold
> > > wallets depending on the application and environment.
> > >
> > > Examples would span wallets on mobile phones, online servers
> > > running protocols like Join Market or Lightning, and the difference
> > > between Electrum and BIP39 mnemonic seed formats. The reference
> > > implementation of Bitcoin Core uses BIP32, while other
> > > cryptocurrencies like Monero use different mnemonic encoding
> > > schemes.
> > >
> > > We must also consider the different variety of physical backups
> > > including paper, metal and other physical storage devices, as well
> > > as the potentially splitting backups across different geographical
> > > locations. This complexity may result in less care being taken with
> > > subsequently generated seeds for new wallets need to be stored and
> > > it ultimately results in less security. In reality, the idea of
> > > having "one seed for all" has proven to be more difficult in
> > > practice than originally thought.
> > >
> > > Since all these derivation schemes are deterministic based on some
> > > initial entropy, this proposal aims to solve the above problems by
> > > detailing a way to deterministically derive the initial entropy
> > > used for new root keychains using a single BIP32 style "master root
> > > key". This will allow one root key or mnemonic to derive any
> > > variety of different root keychains in whatever format is required
> > > (like BIP32 and BIP39 etc).
> > >
> > > =3D=3DSpecification=3D=3D
> > >
> > > Input starts with a BIP32 seed. Derivation scheme uses the format
> > > `m/83696968'/type'/index'` where `type` is the final seed type, and
> > > `index` in the key index of the hardened child private key.
> > >
> > > type
> > >
> > > bits
> > >
> > > output
> > >
> > > 0
> > >
> > > 128
> > >
> > > 12 word BIP39 mnemonic
> > >
> > > 1
> > >
> > > 256
> > >
> > > 24 word BIP39 mnemonic
> > >
> > > 2
> > >
> > > 128
> > >
> > > 12 word Electrum mnemonic
> > >
> > > 3
> > >
> > > 256
> > >
> > > 24 word Electrum mnemonic
> > >
> > > 4
> > >
> > > 256
> > >
> > > WIF for Bitcoin Core
> > >
> > > 5
> > >
> > > 256
> > >
> > > 25 word Monero mnemonic
> > >
> > > Entropy is calculated from the HMAC-SHA512(key=3Dk, msg=3D'bip-entrop=
y-
> > > from-bip32') of the derived 32 byte private key (k). Entropy is
> > > taken from the result according to the number of bits required.
> > > This entropy can then be used as input to derive a mnemonic, wallet
> > > etc according to the`type` specified.
> > >
> > > =3D=3DCompatibility=3D=3D
> > >
> > > In order to maintain the widest compatibility, the input to this
> > > function is a BIP32 seed, which may or may not have been derived
> > > from a BIP39 like mnemonic scheme. This maintains the original
> > > motivation that one backup can store any and all child derivation
> > > schemes depending on the user's preference or hardware signing
> > > devices. For example, devices that store the HD seed as a BIP39
> > > mnemonic, Electrum seed, or BIP32 root key would all be able to
> > > implement this standard.
> > >
> > > =3D=3DDiscussion=3D=3D
> > >
> > > This proposal could be split into multiple discrete BIPs in the
> > > same way that BIP32 described the derivation mechanics, BIP39 the
> > > input encoding with mnemonics, and the derivation paths like BIP44,
> > > BIP49 and BIP84. This has been avoided to reduce complexity. The
> > > resulting private key processed with HMAC-SHA512 and truncated as
> > > necessary. HMAC-SHA512 was chosen because it may have better
> > > compatibility in embedded devices as it's already required in
> > > devices supporting BIP32.
> > >
> > > =3D=3DTest Vectors=3D=3D
> > >
> > > =3D=3D=3DTest case 1=3D=3D=3D
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/0'/0'
> > > BITS REQUIRED: 128
> > >
> > > DERIVED CHILD
> > > WIF=3DL3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
> > > DERIVED CHILD
> > > k=3Dbed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
> > > CHILD ENTROPY=3D6458698fae3578b48a64124ea3514e12
> > > CONVERT ENTROPY TO
> > > WIF=3DKwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
> > > CHILD BIP39 MNEMONIC=3Dgold select glue fragile fiscal fog civil
> > > liquid exchange box fatal caught
> > > CHILD BIP39
> > > SEED=3D2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d23
> > > 8cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
> > > CHILD BIP32 ROOT
> > > KEY=3Dxprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkG
> > > bwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb
> > >
> > > =3D=3D=3DTest case 2=3D=3D=3D
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/1'/0'
> > > BITS REQUIRED: 256
> > >
> > > DERIVED CHILD
> > > WIF=3DL1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
> > > DERIVED CHILD
> > > k=3D8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
> > > CHILD
> > > ENTROPY=3Dec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e5363
> > > 9670b
> > > CONVERT ENTROPY TO
> > > WIF=3DL594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
> > > CHILD BIP39 MNEMONIC=3Dunable imitate test flash witness escape
> > > stadium early inner thank company betray lecture chuckle swift hurt
> > > battle illness bicycle stable fat bronze order high
> > > CHILD BIP39
> > > SEED=3D73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bd
> > > e6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
> > > CHILD BIP32 ROOT
> > > KEY=3Dxprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHf
> > > etVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm
> > >
> > > =3D=3D=3DTest case 3=3D=3D=3D
> > >
> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
> > > employ giant era attitude exit final oval one finger decorate pair
> > > useless super method float toddler dance
> > > MASTER BIP32 ROOT KEY:
> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
> > > PATH: m/83696968'/4'/0'
> > > BITS REQUIRED: 256
> > >
> > > DERIVED CHILD
> > > WIF=3DKwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
> > > DERIVED CHILD
> > > k=3D0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
> > > CHILD
> > > ENTROPY=3D25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d908
> > > 32974
> > > CONVERT ENTROPY TO
> > > WIF=3DKxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
> > > CHILD BIP39 MNEMONIC=3Dcensus ridge music vanish island smooth team
> > > job mammal sing bracket reject smile limit comfort pluck extend
> > > picture race soda suit dose place obtain
> > > CHILD BIP39
> > > SEED=3D4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d5
> > > 4647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
> > > CHILD BIP32 ROOT
> > > KEY=3Dxprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBo
> > > ynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am
> > >
> > > =3D=3DReferences=3D=3D
> > >
> > > BIP32, BIP39
> > >
> > > =3D=3DCopyright=3D=3D
> > >
> > > This BIP is dual-licensed under the Open Publication License and
> > > BSD 2-clause license.
> > >
> > > 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|