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
|
Return-Path: <ethankosakovsky@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 61A57C07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Mar 2020 17:35:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 4FD89876F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Mar 2020 17:35:24 +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 vbQqEGzwTMLd
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Mar 2020 17:35:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by whitealder.osuosl.org (Postfix) with ESMTPS id 44CC3876BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Mar 2020 17:35:22 +0000 (UTC)
Date: Fri, 20 Mar 2020 17:35:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1584725718;
bh=44iYOQPNVpI6We1HMDFrNA5KBadCRLy6gMcbUGtXksA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=u1m3Ckm39cMrnH48jGefiLNE7YUxMIuCzv2MGrUJqLnzXd2SHQZ19of6LG0JDhtBp
vrOAEsk7c4f8PzrLVcSprqUsu20PfzHIZwxuEPOSKvx2PdXXQ12iiRMeWiwOnbM692
7Y8is277Zdaj+QgkqnV91ro2jm/W5Qjav6+n6mEM=
To: Pavol Rusnak <stick@satoshilabs.com>
From: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Reply-To: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Message-ID: <k30xrtCAvArvTk-CMOGYZO7dVLYnnxkH1NJCDVrmNP_d75_sy9ljZ7bwW5UyRe4x6f3W3b476D4YnnXiWOX_gYiH7fdgT65UvRyzVvvVZcg=@protonmail.com>
In-Reply-To: <x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com>
References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
<4cc5041f-3960-8f42-256f-5e00e12d05c5@satoshilabs.com>
<x3wT5bNuZTOXW6pY5-zsu-5BOKYMRqrEoyOaK0kSpprkj7ikNhsLvzBoNqK1_KcWhnsn80Ld0f1jZdhZ4xol0rjnBtxbpH5fm3f2yKTGsVk=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 20 Mar 2020 17:58:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 20 Mar 2020 17:35:24 -0000
I think my proposal can be summarized simply:
1. get a child private key, hmac it and get entropy bits.
2. Use that entropy to feed BIP39 to make a new mnemonic seed
Bitcoin Core hdseed is a private key, so we can also do the same steps here
1. get a child private key, hmac it and get entropy bits.
2. Use that entropy to create a WIF to become the key for hdseed in Bitcoin=
Core.
I standardize this by using paths (like BIP44/49)
m/SEED'/BIP39'/index'
m/SEED'/CORE'/index'
index allows me to generate multiple childs for that type.
Ethen
=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, March 20, 2020 6:34 PM, Ethan Kosakovsky <ethankosakovsky@proton=
mail.com> wrote:
> Pavol,
>
> Yes thank you. I find abstracts hard, I will try again.
>
> Currently I need a separate BIP30 for many of my wallets. I cant have one=
master seed for all my wallets because some are less safe than others and =
storing the master in each environment will increase the chance it could be=
compromised (e.g. hot environments). I cant export a hardened xprv from my=
main BIP32 keychain and import it to my JM/Android wallet because they don=
t support it. There's also a usability issue there since xprvs are not easy=
to type.
>
> e.g.
>
> 1. Join Market server (online)
> 2. Lightning node (online)
> 3. Trezor (offline)
> 4. Smartphone wallet with coffee money (online) (and no HWW support)
> 5. Bitcoin Core (doesn't use BIP39 at all)
>
> I cannot use the same BIP39 seed across all these services. 1,2,4,5 a=
re effectively hot wallets.
>
> The problem is BIP39. BIP32 is fine but the backup process is not hum=
an friendly. It would have been better to simply serialize 128 or 256 bits =
of entropy into words like BIP39 does and be done with it. After that, it's=
all deterministic anyway. Instead BIP39 tries to ensure pseudorandom entro=
py by hash-stretching the initial entropy.
>
> We can already export keychains from BIP32, as xprvs, but there is al=
so no easy way to make as a human readable/typeable like BIP39 mnemonics. M=
ost wallets don't allow you to import an xprv anyway, but again, good luck =
typing it.
>
> What we are left with is an ecosystem that widely implements BIP39, s=
o practically speaking if I want to use multiple wallets and cannot share a=
n existing seed with that device, I need separate 12 or 24 word mnemonics. =
That's 5 times the complexity to store than one (in my case). I need a new =
cryptosteel. If I have two different geological locations for backup, it's =
hard to add more, since I need to travel. The whole point of BIP32 was one =
master key would rule them all - set up once, back up once and it's done. B=
IP39 was simply to make it human friendly to write down the seed on paper.
>
> The easy solution as I see it is have one BIP39 mnemonic as my "maste=
r root key". From there it makes a BIP32 keychain and I can deterministical=
ly create child BIP39 seeds by taking a hardened path, using the private ke=
y as entropy ENT to create a new BIP39 mnemonic. If I do it this way I can =
have one initial backup, and if I need more wallets with a different seed, =
I can do it without worrying about backups. I'm future proof this way.
>
> Ethan
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origi=
nal 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 5:29 PM, Pavol Rusnak stick@satoshilabs.com=
wrote:
>
>
> > On 20/03/2020 16:44, Ethan Kosakovsky via bitcoin-dev wrote:
> >
> > > I would like to present a proposal for discussion and peer review
> >
> > I read your proposal twice and I still don't know what kind of problem
> > are you trying to solve.
> > This should be obvious from the "Abstract" and it's bad if it's not.
> >
> > Best Regards / S pozdravom,
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs
|
