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
|
Return-Path: <somber.night@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3034486E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Nov 2018 10:38:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B304B76F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Nov 2018 10:38:01 +0000 (UTC)
Date: Thu, 08 Nov 2018 10:37:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1541673473;
bh=rnl96aO8I7r9j5u3avq+qIM2CCZ6kLi0LrIcDQBNl30=;
h=Date:To:From:Reply-To:Subject:Feedback-ID:From;
b=HMQcRVje6xej2fqIDHah8vIYwioAWepqJCkTvK1kqh/DRgCUQnbrQEe4VkEXa5Sbj
rnSHbea7HUJriKW7/C1Wzex1QGTkQTiflU5AbBkiREX0uqd88ZOeEboe/T7tgVz9yn
d6vZ+9hJuna3kUpwec7FJa2/CHDOQeBgVwA1R6Cg=
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
From: SomberNight <somber.night@protonmail.com>
Reply-To: SomberNight <somber.night@protonmail.com>
Message-ID: <bANNM0nNJ1cJdrNjvBZfx6O-zwAQ_bg4qPgoYCQGGNQxc0I4AHF0nQCqPYGqYQzLMP07URApaPCOBBPC4whZ77M8amvUdfIo3TFhQjpzNpY=@protonmail.com>
Feedback-ID: daQbrs0DpmRrllQYkksiX-ZnvUtz6D5CoTQt69spWvfuKGSaRC1oU4kOBEGTrhNvt_RBDz2CWSzCwYz6Ytdxzw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FREEMAIL_REPLYTO,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 08 Nov 2018 12:15:47 +0000
Subject: Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support
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: Thu, 08 Nov 2018 10:38:03 -0000
Do you specifically want to support changing the language of seed
words, while keeping the bip32 root seed they generate unchanged?
What is the usecase for this?
You mention that BIP39 already supports a few different languages.
While this is true, many (I would guess most!) wallets only
support the English wordlist.
There are doubts even from the authors of the BIP whether it was
a good idea in the first place to support multiple languages [0].
I don't find this surprising as it seems bad design to have to fix and
maintain a wordlist for every language as the checksum depends on it.
The supported wordlists are effectively a part of the specification,
and every new list would just make that specification larger.
If changing the language of seeds is not a requirement, then look
into Electrum seeds. They are language/wordlist agnostic.
Mnemonic Sentence =3D> PBKDF2 =3D> BIP-0032 Seed
The bip32 seed is derived by hashing the normalized mnemonic, and the
checksum is derived the same way but by using a different cheaper
hash (single round of HMAC-SHA512; generation grinds until it matches
a pattern) [1]. For example, "9dk" is a valid segwit electrum seed.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/0=
15507.html
[1]: http://docs.electrum.org/en/latest/seedphrase.html
> Date: Wed, 7 Nov 2018 00:16:41 +0800
> From: Weiji Guo weiji.g@gmail.com
> Subject: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language
> support
>
> Hello everyone,
>
> I just realized that BIP-0039 is language dependent. I was assuming the
> other way till I looked closer. The way the seed is derived from a BIP-00=
39
> entropy, as is shown below, depends on which language to generate the
> mnemonic sentence:
>
> Entropy <=3D> Mnemonic Sentence =3D> PBKDF2 =3D> BIP-0032 Seed
>
> Therefore when a user choose a non-English mnemonic code he or she is stu=
ck
> with that language. Meanwhile only a few native languages are supported.
>
> SLIP-0039 does not solve this issue in a user friendly way by providing
> only an English wordlist. That's understandable as it aims to provide SSS
> capability. However those users who do not speak English or recognize
> English words will suffer.
>
> What I am trying to bring to attention of the community is that, no matte=
r
> if we make a new version of BIP-0039, or a new BIP (with SSS support), or
> to enhance SLIP-0039, we really need to address this language issue.
>
> Here are what I propose:
>
> 1. The mnemonic code should be only a representation of underlying entro=
py
> or (pre) master secret, seed, whatever. In this way, the same seed/se=
cret
> could be displayed in English or in Chinese or other languages. Then =
there
> could be 3rd party conversion tools to support translations in case a=
ny
> wallet software or device does not support all specified languages. N=
ow it
> looks like:
>
> Mnemonic Sentence <=3D> Entropy =3D> PBKDF2 =3D> BIP-0032 Seed
>
>
> 2. Given that only 8 languages are supported in BIP-0039, we should allow
> the seed/secret to be represented in decimal numbers, each ranging from 0
> to 2047. So those who cannot find a native language support yet having
> difficulty coping words in other languages could choose to just use numbe=
rs.
>
> So far I don't have a preference how this should be implemented. I'd like
> to hear from community first.
|
