summaryrefslogtreecommitdiff
path: root/b1/5e28cef9864c7283446d1825ef0fa2254b55f0
blob: 35725435da7ecf0b36412939655796b6cebea125 (plain)
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
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B41ABE6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jan 2018 19:56:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62FDAA7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jan 2018 19:56:23 +0000 (UTC)
Received: by mail-wm0-f42.google.com with SMTP id g75so4447347wme.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 05 Jan 2018 11:56:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:cc:references:from:message-id:date:user-agent
	:mime-version:in-reply-to:content-language;
	bh=mTlP9twub1NtaUsWMlQttysoYxl4JYDIkKRLXM7GapE=;
	b=Isqcsd9Gn8CsblOSMxGDlYsFjHw7uivv7mTGIMpwR/0eXvR0HiBdPm3TAcFV4d2pAF
	xRaa8KJxEjP1/oy7lIOf1uVZyOmoWk8LlOZSAAIa3nEV0zG9z6RI+9xQLGIUKh9+ucyG
	d0WnoqDrfjSlXaRjxWOq2tXK3nq3f6FxYt6XYbN0eRo84OKurIabv4ilHWdms3CEw6hL
	UrJQqjvcWs5/Hx/0I61Zp8SvvWHx+sSi7fATAWoO4trKUoX5Rzh4DMGKpGd5R0L/94Zh
	//hUhc/OauY0fIF/mZuZYzslaVxxZuKzzlGVf/YgbdYqlQifkUkbPfYcjW4IEx4XOGVP
	7aZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:cc:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-language;
	bh=mTlP9twub1NtaUsWMlQttysoYxl4JYDIkKRLXM7GapE=;
	b=j1CwXXB/eTwK6kIOIYovlGbCHU0U4FN83H0RoVcpHMzz9s+11gAvDzdUIbxHagQtxi
	yCSL6JP1jhcCilXyHHSA3DMyH/hkY4jxOGLOFp0N+ebe/HC8VKcI4OVLxpKXl18+QB73
	MpGekxQythOFIeEaJt+x+beQsu0HkI4E3Lx1S/4ROA5EoeUwatsLreSutOoAlAJK7xJV
	kQZNN/zKGi5/VEGPMeE+gdyeZ/jv4WQNktt95bnVTSzNtUNcyAq1vRlR17RmsC+dMZNr
	EPWdqNq4IXhDrk1RfTO7sZjwm98PpDB8Uo4kgixZsRC7aRlY97DmpBDLCk8aXurPeb3A
	NbSQ==
X-Gm-Message-State: AKGB3mILA2uyH+yfTeVc/KuGqqXCcQBMQM3xvHTRJYMfPRS4yqzMx9NR
	SaB9Z2KFm5Ly2sXG5TVNix7/HA==
X-Google-Smtp-Source: ACJfBouJAX5bdqWKi/wAY21a/Ml4jhVL9kwPcnerMvKhy8zhhA+w6WBfaGDzmLqLtSLL4sQqPPGgEA==
X-Received: by 10.80.177.253 with SMTP id n58mr5689854edd.94.1515182181617;
	Fri, 05 Jan 2018 11:56:21 -0800 (PST)
Received: from ?IPv6:2a01:cb1d:5c:1600:4871:bf04:d8f5:dae4?
	([2a01:cb1d:5c:1600:4871:bf04:d8f5:dae4])
	by smtp.googlemail.com with ESMTPSA id
	o60sm4363771edb.79.2018.01.05.11.56.19
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Jan 2018 11:56:20 -0800 (PST)
To: Alan Evans <thealanevans@gmail.com>
References: <57f5fcd8644c6f6472cd6a91144a6152@nym.zone>
	<BB3FA46E-AA09-4A60-9D0F-8E350015E107@sprovoost.nl>
	<CALPhJax=53dLL9+JDKJC7NdEFFRB2kgKiECSh8PUMzrr2KxWuQ@mail.gmail.com>
	<2A39F6D7-CDF9-4624-BE0A-22C809C8B68C@sprovoost.nl>
	<af76eb48-8ef9-59b5-f7cd-dd3e45277deb@gmail.com>
	<CALPhJaxzayykMMxaa421kfu6QQ77JD7bZJk8+dXT4qSqK_eABg@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <258487be-0b5b-f5fc-e63c-4de7c0e1c874@gmail.com>
Date: Fri, 5 Jan 2018 20:56:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101
	Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CALPhJaxzayykMMxaa421kfu6QQ77JD7bZJk8+dXT4qSqK_eABg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------E3717965248B4CA582D54F05"
Content-Language: fr
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 39: Add language identifier strings for
 wordlists
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 05 Jan 2018 19:56:25 -0000

This is a multi-part message in MIME format.
--------------E3717965248B4CA582D54F05
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

No that's not, some parts of the answer might be but this related, this
just shows how people use wrongly BIP39 and subsequent BIPs (and
globally other things), misleading them, while the advantage of using it
is quite dubious compared to backing up a seed, unless you can convince
me of the contrary


Le 05/01/2018 à 19:16, Alan Evans a écrit :
> Sjors, well in Electrum, validation is optional, but English only. As
> for the Ledger-S, that sounds like a Ledger problem.
>
> Aymeric, that is way off topic, did you reply to wrong email?
>
> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     See: https://github.com/Ayms/bitcoin-transactions/issues/3
>     <https://github.com/Ayms/bitcoin-transactions/issues/3>
>
>     OK, maybe it's my fault, I did not foresee this case, and now it's
>     working for p2sh (non segwit)
>
>     From my standpoint this just means that BIP39/44 stuff should be
>     eradicated (not BIP141 but see what happened...), this is of no
>     use, confusing people, doing dangerous things to recover
>
>     Really is it easier to save x words instead of a seed? Knowing
>     that people are creating several wallets not understanding that
>     this is not the purpose of BIP32?
>
>     Multisig wallets (like Electrum) have created a big mess too, on
>     purpose or no, I don't know, but multisig is for different parties
>     involved, not just one
>
>
>     Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>>     I don’t know about Electrum but many wallets validate the English words, which helps in catching typos.
>>
>>     Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even let you freely type characters; you have to select words from a list.
>>
>>     So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, you’ll have fewer wallets to choose from.
>>
>>     I think it’s better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.
>>
>>     Sjors
>>
>>>     Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans@gmail.com> <mailto:thealanevans@gmail.com> het volgende geschreven:
>>>
>>>     "Very few wallets support anything other than English"
>>>
>>>     By support do you mean allow recovery, validation or generation or all three? For if you can freely type a phrase in (such as Electrum), or even word by word, then the likely-hood is it is supported if they remembered to normalize.
>>>
>>>     Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.
>>>
>>>     But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.
>>>
>>>     Alan
>>>
>>>     On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>     I’m not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.
>>>
>>>     However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
>>>
>>>     I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.
>>>
>>>     This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).
>>>
>>>     A replacement for BIP-39 would be a good opportunity to produce a better English dictionary as Nic Johnson suggested a while ago:
>>>             • all words are 4-8 characters
>>>             • all 4-character prefixes are unique (very useful for hardware wallets)
>>>             • no two words have edit distance < 2
>>>
>>>     Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.
>>>
>>>     A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.
>>>
>>>     For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
>>>     <https://github.com/satoshilabs/slips/issues/103>
>>>
>>>     Sjors
>>>
>>>>     Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>>>>
>>>>     I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes.  At present, the languages are identified only by their names in English.
>>>>
>>>>     Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus.  Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
>>>>
>>>>     As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site.  I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
>>>>
>>>>     https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
>>>>     <https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
>>>>     ```
>>>>           LANG(english,                   u8"English",    "en",   ascii_space ),
>>>>           LANG(chinese_simplified,        u8"汉语", "zh-CN",ascii_space ),
>>>>           LANG(chinese_traditional,       u8"漢語", "zh-TW",ascii_space ),
>>>>           LANG(french,                    u8"Français",   "fr",   ascii_space ),
>>>>           LANG(italian,                   u8"Italiano",   "it",   ascii_space ),
>>>>           LANG(japanese,                  u8"日本語",        "ja",   u8"\u3000"  ),
>>>>           LANG(korean,                    u8"한국어",        "ko",   ascii_space ),
>>>>           LANG(spanish,                   u8"Español",    "es",   ascii_space )
>>>>     ```
>>>>
>>>>     Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar as Hong Kong uses Traditional; and overseas Chinese may use either.  For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
>>>>
>>>>     My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists.  My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
>>>>
>>>>     Should this proposal be “concept ACKed” by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository.  However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
>>>>
>>>>     Prior references:  The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
>>>>     _______________________________________________
>>>>     bitcoin-dev mailing list
>>>>     bitcoin-dev@lists.linuxfoundation.org
>>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>     _______________________________________________
>>>     bitcoin-dev mailing list
>>>     bitcoin-dev@lists.linuxfoundation.org
>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>
>>>
>>>     <signature.asc>
>>
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>     -- 
>     Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
>     <https://github.com/Ayms/bitcoin-transactions>
>     Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
>     <https://github.com/Ayms/zcash-wallets>
>     Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
>     <https://github.com/Ayms/bitcoin-wallets>
>     Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>     Check the 10 M passwords list: http://peersm.com/findmyass
>     Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
>     Peersm : http://www.peersm.com
>     torrent-live: https://github.com/Ayms/torrent-live
>     <https://github.com/Ayms/torrent-live>
>     node-Tor : https://www.github.com/Ayms/node-Tor
>     <https://www.github.com/Ayms/node-Tor>
>     GitHub : https://www.github.com/Ayms
>
>

-- 
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


--------------E3717965248B4CA582D54F05
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>No that's not, some parts of the answer might be but this
      related, this just shows how people use wrongly BIP39 and
      subsequent BIPs (and globally other things), misleading them,
      while the advantage of using it is quite dubious compared to
      backing up a seed, unless you can convince me of the contrary<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 05/01/2018 à 19:16, Alan Evans a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CALPhJaxzayykMMxaa421kfu6QQ77JD7bZJk8+dXT4qSqK_eABg@mail.gmail.com">
      <div dir="ltr">Sjors, well in Electrum, validation is optional,
        but English only. As for the Ledger-S, that sounds like a Ledger
        problem.<br>
        <div><br>
        </div>
        <div>Aymeric, that is way off topic, did you reply to wrong
          email?</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Jan 5, 2018 at 2:08 PM, Aymeric
          Vitte <span dir="ltr">&lt;<a
              href="mailto:vitteaymeric@gmail.com" target="_blank"
              moz-do-not-send="true">vitteaymeric@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <p>See: <a
                  class="m_1128431184814674098moz-txt-link-freetext"
                  href="https://github.com/Ayms/bitcoin-transactions/issues/3"
                  target="_blank" moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions/issues/3</a></p>
              <p>OK, maybe it's my fault, I did not foresee this case,
                and now it's working for p2sh (non segwit)<br>
              </p>
              <p>From my standpoint this just means that BIP39/44 stuff
                should be eradicated (not BIP141 but see what
                happened...), this is of no use, confusing people, doing
                dangerous things to recover<br>
              </p>
              <p>Really is it easier to save x words instead of a seed?
                Knowing that people are creating several wallets not
                understanding that this is not the purpose of BIP32?</p>
              <p>Multisig wallets (like Electrum) have created a big
                mess too, on purpose or no, I don't know, but multisig
                is for different parties involved, not just one<br>
              </p>
              <div>
                <div class="h5"> <br>
                  <div class="m_1128431184814674098moz-cite-prefix">Le
                    05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a
                    écrit :<br>
                  </div>
                  <blockquote type="cite">
                    <pre>I don’t know about Electrum but many wallets validate the English words, which helps in catching typos.

Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even let you freely type characters; you have to select words from a list.

So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, you’ll have fewer wallets to choose from.

I think it’s better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.

Sjors

</pre>
                    <blockquote type="cite">
                      <pre>Op 5 jan. 2018, om 17:27 heeft Alan Evans <a class="m_1128431184814674098moz-txt-link-rfc2396E" href="mailto:thealanevans@gmail.com" target="_blank" moz-do-not-send="true">&lt;thealanevans@gmail.com&gt;</a> het volgende geschreven:

"Very few wallets support anything other than English"

By support do you mean allow recovery, validation or generation or all three? For if you can freely type a phrase in (such as Electrum), or even word by word, then the likely-hood is it is supported if they remembered to normalize.

Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.

But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.

Alan

On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <a class="m_1128431184814674098moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" moz-do-not-send="true">&lt;bitcoin-dev@lists.<wbr>linuxfoundation.org&gt;</a> wrote:
I’m not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.

However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.

I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.

This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).

A replacement for BIP-39 would be a good opportunity to produce a better English dictionary as Nic Johnson suggested a while ago:
        • all words are 4-8 characters
        • all 4-character prefixes are unique (very useful for hardware wallets)
        • no two words have edit distance &lt; 2

Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.

A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.

For my above point and some related ideas, see: <a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/satoshilabs/slips/issues/103" target="_blank" moz-do-not-send="true">https://github.com/<wbr>satoshilabs/slips/issues/103</a>

Sjors

</pre>
                      <blockquote type="cite">
                        <pre>Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <a class="m_1128431184814674098moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" moz-do-not-send="true">&lt;bitcoin-dev@lists.<wbr>linuxfoundation.org&gt;</a> het volgende geschreven:

I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes.  At present, the languages are identified only by their names in English.

Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus.  Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.

As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site.  I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.

<a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99" target="_blank" moz-do-not-send="true">https://github.com/nym-zone/<wbr>easyseed/blob/<wbr>1a6e48bbdac9366d9d5d1912dc062d<wbr>fc3f0db2c6/easyseed.c#L99</a>
```
      LANG(english,                   u8"English",    "en",   ascii_space ),
      LANG(chinese_simplified,        u8"汉语", "zh-CN",ascii_space ),
      LANG(chinese_traditional,       u8"漢語", "zh-TW",ascii_space ),
      LANG(french,                    u8"Français",   "fr",   ascii_space ),
      LANG(italian,                   u8"Italiano",   "it",   ascii_space ),
      LANG(japanese,                  u8"日本語",        "ja",   u8"\u3000"  ),
      LANG(korean,                    u8"한국어",        "ko",   ascii_space ),
      LANG(spanish,                   u8"Español",    "es",   ascii_space )
```

Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar as Hong Kong uses Traditional; and overseas Chinese may use either.  For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?

My general suggestion is that the specification of appropriate strings in <a class="m_1128431184814674098moz-txt-link-freetext" moz-do-not-send="true">bitcoin:bips/bip-0039/bip-<wbr>0039-wordlists.md</a> be made part of the process for accepting new wordlists.  My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.

Should this proposal be “concept ACKed” by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository.  However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.

Prior references:  The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
______________________________<wbr>_________________
bitcoin-dev mailing list
<a class="m_1128431184814674098moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>
<a class="m_1128431184814674098moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a>
</pre>
                      </blockquote>
                      <pre>______________________________<wbr>_________________
bitcoin-dev mailing list
<a class="m_1128431184814674098moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>
<a class="m_1128431184814674098moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a>


&lt;signature.asc&gt;
</pre>
                    </blockquote>
                    <br>
                    <fieldset
                      class="m_1128431184814674098mimeAttachmentHeader"></fieldset>
                    <br>
                    <pre>______________________________<wbr>_________________
bitcoin-dev mailing list
<a class="m_1128431184814674098moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>
<a class="m_1128431184814674098moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a>
</pre>
                  </blockquote>
                  <br>
                </div>
              </div>
              <span class="HOEnZb"><font color="#888888">
                  <pre class="m_1128431184814674098moz-signature" cols="72">-- 
Bitcoin transactions made simple: <a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions" target="_blank" moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions</a>
Zcash wallets made simple: <a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets" target="_blank" moz-do-not-send="true">https://github.com/Ayms/zcash-<wbr>wallets</a>
Bitcoin wallets made simple: <a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets" target="_blank" moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="m_1128431184814674098moz-txt-link-freetext" href="http://peersm.com/getblocklist" target="_blank" moz-do-not-send="true">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="m_1128431184814674098moz-txt-link-freetext" href="http://peersm.com/findmyass" target="_blank" moz-do-not-send="true">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="m_1128431184814674098moz-txt-link-freetext" href="http://torrent-live.org" target="_blank" moz-do-not-send="true">http://torrent-live.org</a>
Peersm : <a class="m_1128431184814674098moz-txt-link-freetext" href="http://www.peersm.com" target="_blank" moz-do-not-send="true">http://www.peersm.com</a>
torrent-live: <a class="m_1128431184814674098moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live" target="_blank" moz-do-not-send="true">https://github.com/Ayms/<wbr>torrent-live</a>
node-Tor : <a class="m_1128431184814674098moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor" target="_blank" moz-do-not-send="true">https://www.github.com/Ayms/<wbr>node-Tor</a>
GitHub : <a class="m_1128431184814674098moz-txt-link-freetext" href="https://www.github.com/Ayms" target="_blank" moz-do-not-send="true">https://www.github.com/Ayms</a></pre>
                </font></span></div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
  </body>
</html>

--------------E3717965248B4CA582D54F05--