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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1VbphU-0005m6-6D
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 10:42:04 +0000
X-ACL-Warn:
Received: from mail-vc0-f176.google.com ([209.85.220.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VbphS-0003bf-P3
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 10:42:04 +0000
Received: by mail-vc0-f176.google.com with SMTP id ia6so1790888vcb.21
for <bitcoin-development@lists.sourceforge.net>;
Thu, 31 Oct 2013 03:41:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-type;
bh=QBAmTdvKX6TFLiQBg6wsO6aBJuYxoM3MBTSkcdqLwFU=;
b=FW2eKI1TODiuX4MTNAXOfNkRcjp21w/4C2B0gTQ40E9cIKBA5Jf1pnIRiU31B7c20n
s22a89SJBl27v7qF08FPHWl8SSLqfGvE+kwpUnITfNNwQUTkXadbPxJTAjQlC88fx6F5
BzVLzy1jljXYO2djhl2UICOcyY+wSK6IqdKw+s+hvqj5rhJK3mhMxO0MqKiA1Ojg+1+p
ckR1woTjlwtYtG13sfClD4LWpthWFnF/Nm9Yfmguw0smgkTIxMOTeaYqmhVgNuZrYell
Cc6d5IPBsIuCnuGC9bR64U0a51Xuh7zCmLpEg/Ag/0B2osdeo7gaZJKzPF5sjqVBwtDg
0iQA==
X-Gm-Message-State: ALoCoQnKxqLkQ+7x5gaZMbCuLqbGJOCf8zwpclxQjcgd5ijaNt+1epXlyJ6K8f+ckF/RtbqHT3cK
X-Received: by 10.58.180.227 with SMTP id dr3mr1385542vec.36.1383216117120;
Thu, 31 Oct 2013 03:41:57 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.59.1.2 with HTTP; Thu, 31 Oct 2013 03:41:27 -0700 (PDT)
In-Reply-To: <52721F47.30206@gmx.de>
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
<CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com>
<526BDEC2.2090709@gmx.de>
<CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
<CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
<52721F47.30206@gmx.de>
From: slush <slush@centrum.cz>
Date: Thu, 31 Oct 2013 11:41:27 +0100
X-Google-Sender-Auth: 9zyxGkMlkzki0LFSFwbds6E3MDI
Message-ID: <CAJna-Hj+q7oyTj8SWiVESPt5Web-mLuDhv7yA8zF5wRD81aBXA@mail.gmail.com>
To: Thomas Voegtlin <thomasv1@gmx.de>
Content-Type: multipart/alternative; boundary=047d7b66fbcf4f25a804ea071943
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VbphS-0003bf-P3
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2013 10:42:04 -0000
--047d7b66fbcf4f25a804ea071943
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Strange, I didn't receive the response from sipa in separate message, so
I'll respond to him at first place.
Le 26/10/2013 23:30, Pieter Wuille a =E9crit :
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
Although many strange practices how to use whole bip32 space are possible,
I think that we may (should?) agree on some "good enough" way how to
discover already used addresses in bip32 space. I read Electrum sources
about bip32 and I see that Electrum still uses quite flat structure (fixed
amount of branches, indexes from 0 to n), which is of course very sane way.
So if I migrate seed to another (non-Electrum) software, I only need to
discover close neighbourhood of the path "0", similarly like Electrum is
doing with "gap limit" in plain old Electrum algorithm, except in two
dimensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1,
...5/5 for gap limit "5"). I don't say such operation is cheap, but this
discovery needs to be done only during the import.
For the reason that I think this is the only sane algorithm of general use
of bip32 space, I still don't see why we do need some extra metadata. I
would understand this if Electrum will use for some strange reason
addresses in higher address space like 2^32-1 or so, but this is not going
to happen at least in Electrum.
> I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
Well, I can imagine that the bip32 compatible software will do full scan of
address space using some gap factor (actually I think "5" is too low by
default) or it can ask for wallet metadata like which software used such
tree before, to speedup scanning process.
I see that Thomas wants to make this automatic and hidden to user and
generally I agree that hiding the compexity to user is a good practice, but
actually this particular situation sounds to me as an exact oposite of
original statement "no metadata in mnemonic".
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets',
ECDSA has one very nice option - (almost) any random data can be used as a
private key. There are very nice schemas possible by using this feature and
requiring private key to be specially crafted just because the user wanted
to use mnemonic schema is very strong limitation to me.
To be specific, we (in cooperation with / inspired by Timo Hanke) developed
method how to prove that the seed generated by Trezor has been created
using combination of computer-provided entropy and device-provided entropy,
without leaking full private information to other computer, just because we
want Trezor to be blackbox-testable and fully deterministic (seed
generation is currently the only operation which uses any source of RNG).
To limit the complexity of such algorithm it is better to produce plain
seed (128, 192 or 256 bits, depends on settings) and then transform the
result of such "deterministic seed" to mnemonic, so for us the
bi-directionality is quite strong requirement. *Maybe* it would be possible
to combine such algorithm and one-way mnemonic together, but it would
complicate the design and I'm sure you understand that we want to keep
things as clear and simple as possible, especially while handling with seed
generation.
> I would strongly prefer if it had at least some strengthening built-in, t=
o
> decrease the impact of worst-case situations.
Agree (hardening is default in bip39).
Marek
--047d7b66fbcf4f25a804ea071943
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Strange, I didn't receive the response from sipa in se=
parate message, so I'll respond to him at first place.<br><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">Le 26/10/2013 23:30, Pie=
ter Wuille a =E9crit :<br>
> I'm not sure whether we're ready to standardize on something l=
ike that<br>> yet, not having established best practices regarding diffe=
rent wallet<br>> structures. I do think we first need to see what possib=
ilities and<br>
> developments are possible related to it.<br><br>Although many strange =
practices how to use whole bip32 space are possible, I think that we may (s=
hould?) agree on some "good enough" way how to discover already u=
sed addresses in bip32 space. I read Electrum sources about bip32 and I see=
that Electrum still uses quite flat structure (fixed amount of branches, i=
ndexes from 0 to n), which is of course very sane way.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So if I mig=
rate seed to another (non-Electrum) software, I only need to discover close=
neighbourhood of the path "0", similarly like Electrum is doing =
with "gap limit" in plain old Electrum algorithm, except in two d=
imensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1, =
...5/5 for gap limit "5"). I don't say such operation is chea=
p, but this discovery needs to be done only during the import.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">For the rea=
son that I think this is the only sane algorithm of general use of bip32 sp=
ace, I still don't see why we do need some extra metadata. I would unde=
rstand this if Electrum will use for some strange reason addresses in highe=
r address space like 2^32-1 or so, but this is not going to happen at least=
in Electrum.</div>
<div class=3D"gmail_extra"><br>> I understand that in<br>> the case o=
f Electrum, there is a strong reason to want this<br>> encapsulated toge=
ther with the seed, but it's not really a requirement<br>> for most =
wallets.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Well, I can=
imagine that the bip32 compatible software will do full scan of address sp=
ace using some gap factor (actually I think "5" is too low by def=
ault) or it can ask for wallet metadata like which software used such tree =
before, to speedup scanning process.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>I see=
that Thomas wants to make this automatic and hidden to user and generally =
I agree that hiding the compexity to user is a good practice, but actually =
this particular situation sounds to me as an exact oposite of original stat=
ement "no metadata in mnemonic".</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra">> =
Regarding other requirements, I wonder why we want the transformation<br>&g=
t; to be bidirectional? If it is just about generating master seeds, one<br=
>
> direction should be enough, and allows far nicer properties w.r.t.<br>=
> security. If we do settle on a standard for 'brainwallets',</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>EC=
DSA has one very nice option - (almost) any random data can be used as a pr=
ivate key. There are very nice schemas possible by using this feature and r=
equiring private key to be specially crafted just because the user wanted t=
o use mnemonic schema is very strong limitation to me.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>To be specific, we (in cooperation with / inspired by Timo Hanke) develope=
d method how to prove that the seed generated by Trezor has been created us=
ing combination of computer-provided entropy and device-provided entropy, w=
ithout leaking full private information to other computer, just because we =
want Trezor to be blackbox-testable and fully deterministic (seed generatio=
n is currently the only operation which uses any source of RNG).</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>To limit the complexity of such algorithm it is better to produce plain se=
ed (128, 192 or 256 bits, depends on settings) and then transform the resul=
t of such "deterministic seed" to mnemonic, so for us the bi-dire=
ctionality is quite strong requirement. *Maybe* it would be possible to com=
bine such algorithm and one-way mnemonic together, but it would complicate =
the design and I'm sure you understand that we want to keep things as c=
lear and simple as possible, especially while handling with seed generation=
.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra">> =
I would=A0strongly prefer if it had at least some strengthening built-in, t=
o<br>> decrease the impact of worst-case situations.<br><br></div><div c=
lass=3D"gmail_extra">
<div class=3D"gmail_extra">Agree (hardening is default in bip39).</div><div=
><br></div><div><br></div><div style>Marek</div></div></div>
--047d7b66fbcf4f25a804ea071943--
|
