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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1VZPTB-0007GC-In
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 18:17:17 +0000
X-ACL-Warn:
Received: from mail-vc0-f171.google.com ([209.85.220.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZPT9-0006J7-Uw
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 18:17:17 +0000
Received: by mail-vc0-f171.google.com with SMTP id lf12so1765748vcb.16
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Oct 2013 11:17:10 -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=ZVUSzJlbb2H+dpm3uvha7fT67OIfK1qZzWUxy3YPkZI=;
b=O8KoCgdbm3+S//fAuceseWRaKhwOgJ3PN8pb6zKWl6aeXoCdj+Gaj3sWzmvPvG9ga1
+kE0rf7+wlM3v/zBNS3C8bWQ2ojFU4YmtZyQUhJrSslpVYbb/MqIbzUVubA2eWb6j3uD
QssrjljoIhrel7NQwtqEVmiqo4IfxlsxcTYew/BCZdpN68s+qBQya/77yEAOpvBBzKNp
jHQKjECuqD8WmBk8aLPfYeAkPgSEHdyQxVJ0+ba2iiJFSksKRAf835GL3p/DoA5W75Ls
MOjh65YJ4t2ogRL8oDrOH6e61ZddAi3ReXg8aKhsubBnJEIeu/nINkoHwpnYiNxHUhE2
0kWQ==
X-Gm-Message-State: ALoCoQlyGaOVvGkutVjXIEIZU7WpmM6nC5/X/+RCEPddniXZUhWl89B71aQbvhEWVmUe36XaMVge
X-Received: by 10.220.164.202 with SMTP id f10mr2050318vcy.25.1382638222564;
Thu, 24 Oct 2013 11:10:22 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.59.1.2 with HTTP; Thu, 24 Oct 2013 11:09:52 -0700 (PDT)
In-Reply-To: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
From: slush <slush@centrum.cz>
Date: Thu, 24 Oct 2013 20:09:52 +0200
X-Google-Sender-Auth: 14hVDQgIZx68_hkwEdBGOXVW06M
Message-ID: <CAJna-HhzGmdoaaoFkp8tBeKCZ4DhDpNO43wzzk_ke7-kH2smbg@mail.gmail.com>
To: "thomasV1@gmx.de" <thomasV1@gmx.de>
Content-Type: multipart/alternative; boundary=001a11c1e9801c13b604e9808c13
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)
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: gmx.de]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VZPT9-0006J7-Uw
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, 24 Oct 2013 18:17:17 -0000
--001a11c1e9801c13b604e9808c13
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1@gmx.de> wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 suffers the same shortcoming: it does nothing
> to help a future replacement, it wants to be final. My first recommendation
> is to allocate a few bits of the mnemonic, in order to encode a "version
> number" along with the checksum bits.
>
>
Two years ago I proposed exactly this and you refused to add extra
information to mnemonic, because "it isn't necessary" and "it makes it
longer to mnemonization". What changed since then?
> The second problem is the wallet structure. There are multiple ways to use
> a BIP32 tree, and each client will certainly handle this differently. For
> Electrum, it is important to be able to recover an entire wallet from its
> mnemonic, using no extra information. Thus, the client needs to know which
> branches of the BIP32 tree are populated by default. This means that the
> "version number" I mentioned will not only be about the seed encoding, but
> it should also give some information about the wallet structure, at least
> in the case of Electrum.
>
>
Hm, what exactly do you need to store about wallet structure? I lived in
opinion that everything is able to recover using CKD function to generate
new addresses and blockchain lookups for their balances.
> The third problem is the dictionary. I do not like the dictionary proposed
> in BIP0039, because it contains too many short words, which are bad for
> memorization (I explained here how I designed the dictionary used by
> Electrum:
> https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I
> had some discussions with slush about this, but I do not think it will ever
> be possible to find a consensus on that topic.
>
>
Yes, that's true. It isn't possible to make everybody 100% happy. At least
I wanted to be constructive and asked you to replace the most problematic
words. No pull request from you so far.
> BIP0039 also suggests to use localized dictionaries, with non-colliding
> word lists, but it is not clear how that will be achieved; it seems to be
> difficult, because languages often have words in common. It looks like a
> first-come-first-served aproach will be used.
>
>
Yes, it was original idea. So far I don't think this is a problem. Of
course some words may have some meaning across languages, but it should be
easy to avoid them. There are tens of thousands words in every language and
we need to pick "only" 2048 words to wordlist.
> For these reasons, I believe that we need a dictionary-independent
> solution. This will allow developers to use the dictionary they like, and
> localization will be easy.
>
I would like to suggest the following solution:
>
>
If I understand this well, it is basically one-way algorithm "mnemonic ->
seed", right? Seed cannot be printed out as mnemonic, because there's
hashing involved, but the bi-directionality has been the original
requirement for such algorithm (at least in Electrum and bip39).
Then, how is this different to picking 12 random words from dictionary and
hashing them together? I don't see any benefit in that "mining" part of the
proposal (except that it is lowering the entropy for given length of
mnemonic).
> This solution makes it possible for developers to define new dictionaries,
> localized or adapted to a particular need.
>
Are your worries about overlapping words across languages a real issue?
slush
--001a11c1e9801c13b604e9808c13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 24, 2013 at 7:29 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:thomasV1@gmx.de" target=3D"_blank">thomasV1@gmx.de</a>><=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<br>
My initial problem was that BIP0039 is not backward compatible with Electru=
m. When trying to solve that, I realized that the seed encoding used in Ele=
ctrum does not help, because it does not contain a version number informati=
on. However, BIP0039 suffers the same shortcoming: it does nothing to help =
a future replacement, it wants to be final. My first recommendation is to a=
llocate a few bits of the mnemonic, in order to encode a "version numb=
er" along with the checksum bits.<br>
<br></blockquote><div><br></div><div style>Two years ago I proposed exactly=
this and you refused to add extra information to mnemonic, because "i=
t isn't necessary" and "it makes it longer to mnemonization&q=
uot;. What changed since then?</div>
<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
The second problem is the wallet structure. There are multiple ways to use =
a BIP32 tree, and each client will certainly handle this differently. For E=
lectrum, it is important to be able to recover an entire wallet from its mn=
emonic, using no extra information. Thus, the client needs to know which br=
anches of the BIP32 tree are populated by default. This means that the &quo=
t;version number" I mentioned will not only be about the seed encoding=
, but it should also give some information about the wallet structure, at l=
east in the case of Electrum.<br>
<br></blockquote><div><br></div><div style>Hm, what exactly do you need to =
store about wallet structure? I lived in opinion that everything is able to=
recover using CKD function to generate new addresses and blockchain lookup=
s for their balances.</div>
<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
The third problem is the dictionary. I do not like the dictionary proposed =
in BIP0039, because it contains too many short words, which are bad for mem=
orization (I explained here how I designed the dictionary used by Electrum:=
<a href=3D"https://bitcointalk.org/index.php?topic=3D153990.msg2167909#msg=
2167909" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D153990=
.msg2167909#msg2167909</a>). I had some discussions with slush about this, =
but I do not think it will ever be possible to find a consensus on that top=
ic.<br>
<br></blockquote><div><br></div><div style>Yes, that's true. It isn'=
;t possible to make everybody 100% happy. At least I wanted to be construct=
ive and asked you to replace the most problematic words. No pull request fr=
om you so far.</div>
<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
BIP0039 also suggests to use localized dictionaries, with non-colliding wor=
d lists, but it is not clear how that will be achieved; it seems to be diff=
icult, because languages often have words in common. It looks like a first-=
come-first-served aproach will be used.<br>
<br></blockquote><div><br></div><div style>Yes, it was original idea. So fa=
r I don't think this is a problem. Of course some words may have some m=
eaning across languages, but it should be easy to avoid them. There are ten=
s of thousands words in every language and we need to pick "only"=
2048 words to wordlist.</div>
<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
For these reasons, I believe that we need a dictionary-independent solution=
. This will allow developers to use the dictionary they like, and localizat=
ion will be easy.=A0<br></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would like to suggest the following solution:<br>
<br></blockquote><div><br></div><div style>If I understand this well, it is=
basically one-way algorithm "mnemonic -> seed", right? Seed c=
annot be printed out as mnemonic, because there's hashing involved, but=
the bi-directionality has been the original requirement for such algorithm=
(at least in Electrum and bip39).</div>
<div style><br></div><div style>Then, how is this different to picking 12 r=
andom words from dictionary and hashing them together? I don't see any =
benefit in that "mining" part of the proposal (except that it is =
lowering the entropy for given length of mnemonic).</div>
<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This solution makes it possible for developers to define new dictionaries, =
localized or adapted to a particular need.<br></blockquote><div><br></div><=
div style>Are your worries about overlapping words across languages a real =
issue?</div>
<div style>=A0</div><div style>slush</div></div></div></div>
--001a11c1e9801c13b604e9808c13--
|
