summaryrefslogtreecommitdiff
path: root/f2/e06a9357d3bfd01b0d594ba484fa42793a89b8
blob: 2c2f068501cd9b2e69cc32815f71021f7b0a10aa (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
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B5AC1CC3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jan 2018 17:13:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
	[66.111.4.26])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3F154E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jan 2018 17:13:26 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id 8D8F622449;
	Fri,  5 Jan 2018 12:13:25 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
	by compute1.internal (MEProxy); Fri, 05 Jan 2018 12:13:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
	cc:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; bh=HhwzSWdBeijKJaF3YIdq8vFVjUroL5+w1zEHUC4PjPg=; b=cMiWRm/B
	2DsTycSXFf1t9seuV0b8AtI1AJhTO1PtLRWzljt1BxV+KNa7lG9kPCfN+7x3lEDr
	MQLXYd+yqZEI6tNkURXvvZS87vVskgBBSB+faw9nLjPHtFQP2EmQRzQwRLwtq3qy
	O8SmnrJPABGS5P1WgDFJlNxXPMwT80e+CWpZjKGoiZeHUxFM5OTAkRrgM8FgaLsl
	kMn+lf4BzB3L1n7DQuRolmknJKl36/Fvu0BfAE9tAEIXdyHxic2/b2/Jv9AkX8kH
	diTxNrw6FVb8Fz0JEyUVARlt1qaQ806I+8SgnqF2VjyDm8wwc1MtuOxeMClwjS6M
	QqewkEKGygX5Qg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; bh=HhwzSWdBeijKJaF3YIdq8vFVjUroL
	5+w1zEHUC4PjPg=; b=C4/JVQ65utdvXqm7RNgjyt3J8H1WrxhIyInolq+b1bpnJ
	trxIVWoyTXMNz8+ZipjrgySBr4IYo2KaiV6H6ePsjLeMHbQJIIcFKzn1vKupE7hm
	wG4/Dxzj7mfxgG5jfqcTutqdOYeWO4rUfwdXJBKyIdeAg9mG6CEMIA6tnolikpEl
	N2W1yezDv0CRBH3YKWElsXBg6Nkpcf3s6AMNfCHDy9G+9AgrO/yGI1c1NV2z0Ne9
	WXZCZbQGR4iaIhhigEkC5BwDVYUQvnp4RhRWc9l0b08t2aqqatdyc6iwFb+oa83h
	qofV1DfkIkBGhqCtK1xXFm/lHsjCAgNUdl6Jy3rtg==
X-ME-Sender: <xms:NbJPWhJA-Jv-2okvCudIVId8fjnaY_dwTRmcR5w1yUkPH4Wsy_UIeQ>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
	[84.105.61.15])
	by mail.messagingengine.com (Postfix) with ESMTPA id CFBCB24839;
	Fri,  5 Jan 2018 12:13:24 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <2A39F6D7-CDF9-4624-BE0A-22C809C8B68C@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_04EB0B09-2CFA-4ACF-96D0-53199B7DCB31";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 5 Jan 2018 18:13:23 +0100
In-Reply-To: <CALPhJax=53dLL9+JDKJC7NdEFFRB2kgKiECSh8PUMzrr2KxWuQ@mail.gmail.com>
To: Alan Evans <thealanevans@gmail.com>
References: <57f5fcd8644c6f6472cd6a91144a6152@nym.zone>
	<BB3FA46E-AA09-4A60-9D0F-8E350015E107@sprovoost.nl>
	<CALPhJax=53dLL9+JDKJC7NdEFFRB2kgKiECSh8PUMzrr2KxWuQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 05 Jan 2018 17:20:58 +0000
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 17:13:28 -0000


--Apple-Mail=_04EB0B09-2CFA-4ACF-96D0-53199B7DCB31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I don=E2=80=99t 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=E2=80=99t 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=E2=80=99ll have =
fewer wallets to choose from.

I think it=E2=80=99s 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> het =
volgende geschreven:
>=20
> "Very few wallets support anything other than English"
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Alan
>=20
> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I=E2=80=99m 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.
>=20
> However, because people can memorize things better in their native =
tongue, supporting multiple languages seems quite useful.
>=20
> 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.
>=20
> 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).
>=20
> A replacement for BIP-39 would be a good opportunity to produce a =
better English dictionary as Nic Johnson suggested a while ago:
>         =E2=80=A2 all words are 4-8 characters
>         =E2=80=A2 all 4-character prefixes are unique (very useful for =
hardware wallets)
>         =E2=80=A2 no two words have edit distance < 2
>=20
> 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.
>=20
> 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.
>=20
> For my above point and some related ideas, see: =
https://github.com/satoshilabs/slips/issues/103
>=20
> Sjors
>=20
> > Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev =
<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/1a6e48bbdac9366d9d5d1912dc062dfc=
3f0db2c6/easyseed.c#L99
> > ```
> >       LANG(english,                   u8"English",    "en",   =
ascii_space ),
> >       LANG(chinese_simplified,        u8"=E6=B1=89=E8=AF=AD", =
"zh-CN",ascii_space ),
> >       LANG(chinese_traditional,       u8"=E6=BC=A2=E8=AA=9E", =
"zh-TW",ascii_space ),
> >       LANG(french,                    u8"Fran=C3=A7ais",   "fr",   =
ascii_space ),
> >       LANG(italian,                   u8"Italiano",   "it",   =
ascii_space ),
> >       LANG(japanese,                  u8"=E6=97=A5=E6=9C=AC=E8=AA=9E",=
        "ja",   u8"\u3000"  ),
> >       LANG(korean,                    u8"=ED=95=9C=EA=B5=AD=EC=96=B4",=
        "ko",   ascii_space ),
> >       LANG(spanish,                   u8"Espa=C3=B1ol",    "es",   =
ascii_space )
> > ```
> >
> > Per the comment at #L85 of the quoted file, I also know that for my =
short identifiers for Chinese, =E2=80=9Czh-CN=E2=80=9D and =E2=80=9Czh-TW=E2=
=80=9D, are imprecise at best=E2=80=94insofar 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 =E2=80=9Cconcept ACKed=E2=80=9D 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
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> <signature.asc>


--Apple-Mail=_04EB0B09-2CFA-4ACF-96D0-53199B7DCB31
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlpPsjMACgkQV/+b28ww
EAm9EQ/+JpHbzxN2YwGegxOe7cQ23PJSpyPuMskzxGvLEp7hW0W52X0OqIdAfhEu
51CZKULHWeMzXV9tFNzWmdAJUHLEQKMUX3xAMSgKmn6dUeMHx1348HpWtXCQ3Vqg
7JfFSPn8R/pXgzXU+G3OGJSbboZ0ngMLFk7ijxu8MT4WkvD09kuMuIBaNizWLv8G
AkFBLWo0cKaaFjN3eVIuVqZSYRdQ8s+bp54m/izdpUDpTbUM8WV83pv0DXr0tNF8
W0pLkX83LiSY168uobtJYRwgXiTmpbBtWeo5xqzNvzKuQHlK79EhEoz7eRvXne8H
Uzb7NxZv+yeY8kL1WINvigv4haMo2qGSU+h4u0l5BpJJ0fHjeh5SYwVRH9QZgomq
RHv1JoIzWyhWqBAgxf+Q4+JNWL2JegbJYU5+8qIETwoyjiXIce0HD9j9RpGuFN5A
FXmVfUWM13k/TLYqv8GaeN5w/4A6VVPX6fBovX4kGTZPr4IbcLJSM8d6OEUNECnw
WbLwW1YZCD3gQcy3OWkWCip1lc81nizbrnxjQ85lKrT/iyEI8TRAaRU0YdYMpERD
RKEiEp/bQKofzx4VTQW1EoByP9CAMKwEmvgj802E/1DZ5uluZ3luCBBKJnbTrAvl
3wT8DRuAh2TSQi+RY+21YPCXijC8Gd3pYxflccXoBXEDc7ETG8c=
=VMn5
-----END PGP SIGNATURE-----

--Apple-Mail=_04EB0B09-2CFA-4ACF-96D0-53199B7DCB31--