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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1W5Olw-0002aA-R3
for bitcoin-development@lists.sourceforge.net;
Tue, 21 Jan 2014 00:00:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.17.22 as permitted sender)
client-ip=212.227.17.22; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.17.22])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1W5Olu-0003f6-Qt
for bitcoin-development@lists.sourceforge.net;
Tue, 21 Jan 2014 00:00:52 +0000
Received: from [192.168.1.27] ([86.73.30.122]) by mail.gmx.com (mrgmx001) with
ESMTPSA (Nemesis) id 0M39zL-1VDiQ842n1-00swb9 for
<bitcoin-development@lists.sourceforge.net>;
Tue, 21 Jan 2014 01:00:44 +0100
Message-ID: <52DDB8AB.4010103@gmx.de>
Date: Tue, 21 Jan 2014 01:00:43 +0100
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAJna-HjGHpru6Lpv_tXUkWR2mX-=fobzojtHYvSRJy6+CMesOA@mail.gmail.com> <CANg-TZCrpT-YJ0WV9VY6w-PtCiz2YRMBCMvmjneDz13j2namkw@mail.gmail.com> <20140120223502.GA1055@petertodd.org> <CANOOu=_pVCPiDtbqc3EwToZWzjLw4UqOvpsu2Wrt4eDKC7g_2g@mail.gmail.com>
<CAJna-HgStwQQUiNZfJrFS1SduuzEEVrF=qmVe23uqZUNhHkOHA@mail.gmail.com>
In-Reply-To: <CAJna-HgStwQQUiNZfJrFS1SduuzEEVrF=qmVe23uqZUNhHkOHA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------080101000707070900040601"
X-Provags-ID: V03:K0:kfmcVwh+QYFF0iZUOhiKnyOaIRWanQ8tpHUSRUD4RqntoBnSe1b
sc9zF9oTlwAlSJf2haPIb9eICYOmKuBy/VfeXM070+0DZVPMce67xn/ip+q4XExvHz3rVkX
Zsr12fE35E9oU8kRRUaM9Kx7cjnXA+Qo2uMj1/JCe1Gzuz+Nw/0dAB8W1q0EegMQJdmguQh
VHFIbYS3PpQk3fa0ctliQ==
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(thomasv1[at]gmx.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.22 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (thomasv1[at]gmx.de)
1.0 HTML_MESSAGE BODY: HTML included in message
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1W5Olu-0003f6-Qt
Subject: Re: [Bitcoin-development] BIP0039: Final call
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: Tue, 21 Jan 2014 00:00:53 -0000
This is a multi-part message in MIME format.
--------------080101000707070900040601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.
IMO the right approach is to implement checksums that do not depend
on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod 2^k
== 0 )
this would also allow us to implement sipa's variable stretching proposal.
I understand this is not possible because of the computational
requirements of devices such as trezor.
I am leaning toward considering these devices as a nonstandard case,
instead of enforcing a given wordlist in the standard.
Thomas
Le 21/01/2014 00:18, slush a écrit :
>
> On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca
> <christophe.biocca@gmail.com <mailto:christophe.biocca@gmail.com>> wrote:
>
> I remember the wordlist choice getting bikeshedded to death a
> month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can correct a
> user's typos regardless of the original generator.
>
>
> That's exactly our attitude. We realized that have a community-wide
> agreement on the wordlist itself is simply imposible, so to reach at
> least some consensus we split the proposal to two parts - one what is
> essential to call itself a "bip39 compatible", i.e. converting the
> mnemonic to bip32 node and second which is optional, including our
> proposed wordlist, which has some advanced features like checksums
> etc. Now it is up to client developers to decide if they really insist
> on their superior wordlist or if they'll implement checksums following
> the full specification.
>
> Those who don't like it will have to deal with the compatibility
> concerns themselves, or get an alternate wordlist approved as a BIP.
>
> Odds are no one will go that route.
>
> At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> which is 100% of clients which expressed interest in bip39 :-).
>
> slush
>
--------------080101000707070900040601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi slush, <br>
<br>
Thank you for your new proposal; it seems to be a compromise.<br>
<br>
@Christophe Biocca:<br>
If the wordlist becomes part of the standard, then we will run into
<br>
problems of collisions once users ask for wordlists in every
language.<br>
<br>
IMO the right approach is to implement checksums that do not depend
<br>
on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod
2^k == 0 )<br>
this would also allow us to implement sipa's variable stretching
proposal.<br>
<br>
I understand this is not possible because of the computational <br>
requirements of devices such as trezor. <br>
<br>
I am leaning toward considering these devices as a nonstandard case,
<br>
instead of enforcing a given wordlist in the standard. <br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Le 21/01/2014 00:18, slush a écrit :<br>
</div>
<blockquote
cite="mid:CAJna-HgStwQQUiNZfJrFS1SduuzEEVrF=qmVe23uqZUNhHkOHA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jan 21, 2014 at 12:06 AM,
Christophe Biocca <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:christophe.biocca@gmail.com"
target="_blank">christophe.biocca@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
remember the wordlist choice getting bikeshedded to death
a month ago.<br>
<br>
I would just include the wordlist as part of the standard
(as a<br>
recommendation) so that fully compliant implementations
can correct a<br>
user's typos regardless of the original generator.<br>
<br>
</blockquote>
<div><br>
</div>
<div>That's exactly our attitude. We realized that have a
community-wide agreement on the wordlist itself is simply
imposible, so to reach at least some consensus we split
the proposal to two parts - one what is essential to call
itself a "bip39 compatible", i.e. converting the mnemonic
to bip32 node and second which is optional, including our
proposed wordlist, which has some advanced features like
checksums etc. Now it is up to client developers to decide
if they really insist on their superior wordlist or if
they'll implement checksums following the full
specification.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAJna-HgStwQQUiNZfJrFS1SduuzEEVrF=qmVe23uqZUNhHkOHA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Those
who don't like it will have to deal with the compatibility<br>
concerns themselves, or get an alternate wordlist approved
as a BIP. </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Odds
are no one will go that route.<br>
<br>
</blockquote>
<div> </div>
<div>At least Trezor and bitcoinj (Multibit) seems to be
going in this way, which is 100% of clients which
expressed interest in bip39 :-).</div>
<div><br>
</div>
<div>slush</div>
<div> </div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------080101000707070900040601--
|
