path: root/2b/52ba5814939683cdf5d77d369b8d34f138c777

Return-Path: <shatzakis@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 04A97B73
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Nov 2018 19:54:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com
	[209.85.222.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC1F5782
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Nov 2018 19:54:14 +0000 (UTC)
Received: by mail-qk1-f173.google.com with SMTP id o125so50712014qkf.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Nov 2018 11:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=yiIV7fhJaVZX9H/W7kZgm9J0eb6IIBHEoGk15414j7c=;
	b=K5pqEGl+VB4nbfy0VkShp7RaXi+QIOyF/ujlFzC20cRBNFNB0pxhvMzu8pMBesnz9W
	W/Vn0DMChwy04iU4i3S+TxD/8/G9KQXsZRTcfsjmyfDSHMdRvM8qKkHEt3n/FuXUppbm
	mqdGd/iX/7uiMwPoLXrNu7a8QnwLLOBVCcg+ruHnhvDouAnBcWZ4Cngz1cFB9F3L6Ohs
	/lhSvcdKCmbpa0k1LyxXMCTdeSjTJ4Chg3CbWyyb4hjt2CP8fVU/2AuFa0dGKwP8xMA3
	e0psE+eH2L2FH9+XXvBPPJ+BKDWSdQqNYde+VgAuvDRyJUjIphzVA7cPtNIMQ5Bn8fvU
	2Skg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=yiIV7fhJaVZX9H/W7kZgm9J0eb6IIBHEoGk15414j7c=;
	b=Vctk8nKYKCCH+eSzLiw12u1TsOugSMjGAvAHRhCf4Y7n/lenH2f8+qLGJM9+AhnLO7
	naQ1F+f3VOQxYZ0o+n+r972tzgXjXs54ObBHO+7kwlOZwZA5Y147m6LEg8QztXpGiguF
	SFDncYR/9k4mftEcWZNYSJwasexW4EG7Loc3lWnkXC0bkE8sntiRsPtVrW1OhxbagU8S
	WNXvg7clfYDGwMWV3rZMyGVZ89+YI3v0s32AX+x3CcsEqOn4LLoRzppot8UFRAfxsF0K
	MshvHaGaDszYYv9o/MnxCjaPDW/hFtXtdBf55P5aVNm5hbllSuCrpA1z1gWOtzzXc5Y9
	ByJw==
X-Gm-Message-State: AGRZ1gI0rIRE38jxZPNaGZTlQTIQggVUdWsmSeLxsF94gJ39AUmvxK8Q
	cyNmAK8CBw/7I7tikUwdFnvd1Y+ftFTb8FmqY5TmtELP
X-Google-Smtp-Source: AJdET5dAOO1YCsheKxM6/JA6f1kcBiGTLLtmF+po1xahzeHlSLirxQQLHIf0HYcHMHwjwlsPkk5UEuU0Oa6oXIQm+TQ=
X-Received: by 2002:aed:2f07:: with SMTP id l7mr22338256qtd.71.1542657253368; 
	Mon, 19 Nov 2018 11:54:13 -0800 (PST)
MIME-Version: 1.0
References: <CABsxsG27bJN0vGRJOP3=zriPvkL+G8n3t2nd6Y8L6KwW4ePdeg@mail.gmail.com>
In-Reply-To: <CABsxsG27bJN0vGRJOP3=zriPvkL+G8n3t2nd6Y8L6KwW4ePdeg@mail.gmail.com>
From: Steven Hatzakis <shatzakis@gmail.com>
Date: Mon, 19 Nov 2018 21:54:01 +0200
Message-ID: <CABsxsG1QZ7h9Cxs=rzuBEOsMY+oJ1n4q5zhRxVE1JsS1e-hgew@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000098e7c1057b09e141"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Mon, 19 Nov 2018 20:21:09 +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: Mon, 19 Nov 2018 19:54:16 -0000

--00000000000098e7c1057b09e141
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Weiji, and Everyone,

I think this is an important topic so sharing my two cents in case in
helps: It makes sense for users to know that they can't merely just
translate a word from one language into another and expect the same
underlying entropy to be mapped, as the wordlists are not the same (i.e.
words differ at the same index values across languages).

However, while the words for each language cannot translate directly to
their equivalent in another language, in terms of entropy (bits), the
underlying entropy is, in fact, the same, when comparing mnemonics
generated across languages (see English/Spanish comparison below) when
sourced from the same initial entropy.

Importantly, the entropy is a pre-image of the resulting mnemonic and
doesn't change as the language changes, where the only changes are to the
resulting words which depend on the language chosen, for a given entropy
string. Ideally, the wallet/software should deal with these nuances, I
don't think the protocol needs any revision (except for how the BIP39 seed
is derived, perhaps), even if someone made up their own wordlist, as long
as the wallet/software has a copy of it to map those words to the
underlying index values, it's *those underlying index values and the
entropy they map too is what really matters**. *

I fully support the idea for users to back up this pre-image (initial
entropy) as it can also be used to check the validity of the mnemonic and
check that it mapped correctly, see Ian Coleman's BIP39 tool which shows
index values, a feature that I proposed last year and was since
implemented. Below is an example of how two mnemonics generated with the
same entropy will produce different BIP39 seeds.

* Example initial entropy of 128 bits +4 bit checksum derived from hash of
byte array: *

10001101000 01010100100 11011010000 11100001101 01010001101 00010010001
01100000010 10101110100 00100100011 11110000111 01100011010 1100010 (+1110
checksum)

*In English*: minimum fee sure ticket faculty banana gate purse caught
valley globe shift

The same initial entropy above (all 132 bits) produces this mnemonic:

*In Spanish*: mercado faja soledad tarea evadir aries gafas peine bu=CC=81h=
o
tumor gerente reja

And the underlying index values below are the same for both the English and
Spanish mnemonics above:

Word Indexes: 1128, 676, 1744, 1805, 653, 145, 770, 1396, 291, 1927, 794,
1582

*ISSUE AT HAND*:  While the initial entropy is the same, and word indexes
the same for a given entropy, (i.e. same pre-image), the resulting BIP39
seed is not the same when comparing the above English mnemonic with its
Spanish counterpart:

   - *English BIP39 seed:*
   ce7618075099c89e986f18dc495daa3be190450ed07bef77d4334a54dbc1cd7e205797ff=
ed2615ac0999a5d691f65bf316e2cdbfd2c9d7d90b03e77ff1e6a6f5
   - *Spanish BIP39 seed*:
   9f164de0fb09af51b5831886e424d6d2479d49b5e5a1b28f5c09467ea36089b144cd94bb=
9b636b3c27ccff96a8958e5b7ce43cf1dea81423fc66fa7fef0aea2c


*Option 1:* Without changing anything in terms of the entropy
generation/mapping process in the BIP39 spec, the wallet/client-side
software would ideally recognize the language and show the corresponding
index value per wordlist, and reverse-calculate the entropy and then re-map
it to the language selected.

*Option 2*: Perhaps a revision is needed to how the BIP39 seed is generated
in the first place, such as by hashing the entropy instead of the words.
Any thoughts on how viable that could be where the initial entropy is fed
into the PBKDF2 function and not the words?

*Closing thoughts and tiny checksum nitpick: *

      - The multiple BIP39 seeds per language lend some similarities to
BIP44 multi-account, so perhaps this can be an advantage, depends on how it
is applied in UI/UX's (compared to having one BIP39 seed regardless of
language, for a given initial entropy).
      - There is perhaps an opportunity to add greater detail to the BIP39
spec in terms of standards/best-practices for computing checksum values, as
some software may be hashing bits, versus hashing bytes, or hashing the
entropy as a hex string, etc.. for a given entropy, which will result in
different checksum values for the same "valid" mnemonic, that might not be
"valid" in another wallet which may format the data differently before
hashing to compute the checksum.


Best regards,

Steven Hatzakis

_______________
[bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support*Weiji
Guo* weiji.g
at gmail.com
<bitcoin-dev%40lists.linuxfoundation.org?Subject=3DRe:%20Re%3A%20%5Bbitcoin=
-dev%5D%20%20BIP-%20%26%20SLIP-0039%20--%20better%20multi-language%20suppor=
t&In-Reply-To=3D%3CCA%2Bydi%3DLM%2Bq-9WKewb%3D65tWCqM1cPMoWEeWq5XAxdqg4rz%3=
DZJ6g%40mail.gmail.com%3E>
*Tue Nov 6 16:16:41 UTC 2018*


   - Previous message: [bitcoin-dev] draft proposal: change forwarding
   (improved fungibility through wallet interoperability)
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/0=
16469.html>
   - Next message: [bitcoin-dev] Considering starting a toy full-node
   implementation. Any advice?
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/0=
16470.html>
   - *Messages sorted by:* [ date ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/d=
ate.html#16468>
    [ thread ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/t=
hread.html#16468>
    [ subject ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/s=
ubject.html#16468>
    [ author ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/a=
uthor.html#16468>

------------------------------

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-0039
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 stuck
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 matter
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 entropy
or (pre) master secret, seed, whatever. In this way, the same seed/secret
could be displayed in English or in Chinese or other languages. Then there
could be 3rd party conversion tools to support translations in case any
wallet software or device does not support all specified languages. Now 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 numbers=
.

So far I don't have a preference how this should be implemented. I'd like
to hear from community first.

Thanks,

Weiji Guo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20=
181107/88677440/attachment.html>

------------------------------


   - Previous message: [bitcoin-dev] draft proposal: change forwarding
   (improved fungibility through wallet interoperability)
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/0=
16469.html>
   - Next message: [bitcoin-dev] Considering starting a toy full-node
   implementation. Any advice?
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/0=
16470.html>
   - *Messages sorted by:* [ date ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/d=
ate.html#16468>
    [ thread ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/t=
hread.html#16468>
    [ subject ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/s=
ubject.html#16468>
    [ author ]
   <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/a=
uthor.html#16468>

------------------------------
More information about the bitcoin-dev mailing list
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

--00000000000098e7c1057b09e141
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Hi=C2=A0<span style=3D"color:rgb(0,0,0);white-space:pre=
-wrap;font-family:Arial,Helvetica,sans-serif">Weiji, and Everyone,</span><b=
r></div><div class=3D"gmail_quote"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D=
"font-family:arial,helvetica,sans-serif"><span style=3D"color:rgb(0,0,0);wh=
ite-space:pre-wrap;font-family:Arial,Helvetica,sans-serif"><br></span></div=
><div style=3D"font-family:arial,helvetica,sans-serif"><span style=3D"color=
:rgb(0,0,0);white-space:pre-wrap;font-family:Arial,Helvetica,sans-serif">I =
think this is an important topic so sharing my two cents in case in helps: =
</span>It makes sense for users to know that they can&#39;t merely just tra=
nslate a word from one language into another and expect the same underlying=
 entropy to be mapped, as the wordlists are not the same (i.e. words differ=
 at the same index values across languages).=C2=A0</div><div style=3D"font-=
family:arial,helvetica,sans-serif"><br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif">However, while the words for each language cannot t=
ranslate directly to their equivalent in another language, in=C2=A0terms of=
 entropy (bits), the underlying entropy is, in fact, the same, when compari=
ng mnemonics generated across languages (see English/Spanish comparison bel=
ow) when sourced from the same initial entropy.<br></div><div style=3D"font=
-family:arial,helvetica,sans-serif"><br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif">Importantly, the entropy is a pre-image of the res=
ulting mnemonic and doesn&#39;t change as the language changes, where the o=
nly changes are to the resulting words which depend on the language chosen,=
 for a given entropy string. Ideally, the wallet/software should deal with =
these nuances, I don&#39;t think the protocol needs any revision (except fo=
r how the BIP39 seed is derived, perhaps), even if someone made up their ow=
n wordlist, as long as the wallet/software has a copy of it to map those wo=
rds to the underlying index values, it&#39;s=C2=A0<b>those underlying index=
 values and the entropy they map too is what really matters</b><b>.=C2=A0</=
b></div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif">I fully support the idea=
 for users to back up this pre-image (initial entropy) as it can also be us=
ed to check the validity of the mnemonic and check that it mapped correctly=
, see Ian Coleman&#39;s BIP39 tool which shows index values, a feature that=
 I proposed last year and was since implemented. Below is an example of how=
 two mnemonics generated with the same entropy will produce different BIP39=
 seeds.<br></div><div style=3D"font-family:arial,helvetica,sans-serif"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif"><b>=C2=A0Exampl=
e initial entropy of 128 bits +4 bit checksum derived from hash of byte arr=
ay:=C2=A0</b></div><div style=3D"font-family:arial,helvetica,sans-serif"><b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif"><span style=
=3D"color:rgb(51,51,51);font-family:&quot;Helvetica Neue&quot;,Helvetica,Ar=
ial,sans-serif;font-size:14px">10001101000 01010100100 11011010000 11100001=
101 01010001101 00010010001 01100000010 10101110100 00100100011 11110000111=
 01100011010 1100010 (+1110 checksum)</span><br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif"><br></div><div><font face=3D"arial, helvet=
ica, sans-serif"><b>In English</b>: minimum fee sure ticket faculty banana =
gate purse caught valley globe shift</font><br></div><div><font face=3D"ari=
al, helvetica, sans-serif"><br></font></div><div><font face=3D"arial, helve=
tica, sans-serif">The same initial entropy above (all 132 bits) produces th=
is mnemonic:</font></div><div><font face=3D"arial, helvetica, sans-serif"><=
br></font></div><div><font face=3D"arial, helvetica, sans-serif"><b>In Span=
ish</b>:=C2=A0mercado faja soledad tarea evadir aries gafas peine bu=CC=81h=
o tumor gerente reja</font></div><div><font face=3D"arial, helvetica, sans-=
serif"><br></font></div><div><font face=3D"arial, helvetica, sans-serif">An=
d the underlying index values below are the same for both the English and S=
panish mnemonics above:=C2=A0</font></div><div><font face=3D"arial, helveti=
ca, sans-serif"><br></font></div><div><span style=3D"color:rgb(51,51,51);fo=
nt-family:&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:1=
4px;font-weight:bold;text-align:right">Word Indexes:=C2=A0</span><span styl=
e=3D"color:rgb(51,51,51);font-family:&quot;Helvetica Neue&quot;,Helvetica,A=
rial,sans-serif;font-size:14px">1128, 676, 1744, 1805, 653, 145, 770, 1396,=
 291, 1927, 794, 1582</span></div><div><span style=3D"font-family:arial,hel=
vetica,sans-serif"><br></span></div><div><span style=3D"font-family:arial,h=
elvetica,sans-serif"><font color=3D"#ff0000"><b>ISSUE AT HAND</b></font>:=
=C2=A0 While the initial entropy is the same, and word indexes the same for=
 a given entropy, (i.e. same pre-image), the resulting BIP39 seed is not th=
e same when comparing the above English mnemonic with its Spanish counterpa=
rt:</span><br></div><div><ul><li><b>English BIP39 seed:</b>=C2=A0<font face=
=3D"arial, helvetica, sans-serif">ce7618075099c89e986f18dc495daa3be190450ed=
07bef77d4334a54dbc1cd7e205797ffed2615ac0999a5d691f65bf316e2cdbfd2c9d7d90b03=
e77ff1e6a6f5</font><br></li><li><b>Spanish BIP39 seed</b>:<font face=3D"ari=
al, helvetica, sans-serif">9f164de0fb09af51b5831886e424d6d2479d49b5e5a1b28f=
5c09467ea36089b144cd94bb9b636b3c27ccff96a8958e5b7ce43cf1dea81423fc66fa7fef0=
aea2c</font><br></li></ul></div><div><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif"><b>Option 1:</b> Without changing anything in ter=
ms of the entropy generation/mapping process in the BIP39 spec, the wallet/=
client-side software would ideally recognize the language and show the corr=
esponding index value per wordlist, and reverse-calculate the entropy and t=
hen re-map it to the language selected.=C2=A0</div><div style=3D"font-famil=
y:arial,helvetica,sans-serif"><br></div><div><b style=3D"font-family:arial,=
helvetica,sans-serif">Option 2</b><font face=3D"arial, helvetica, sans-seri=
f">: Perhaps a revision is needed to how the BIP39 seed is generated in the=
 first place, such as by hashing the entropy instead of the words. Any thou=
ghts on how viable that could be where the initial entropy is fed into the =
PBKDF2 function and not the words?</font></div><div><font face=3D"arial, he=
lvetica, sans-serif"><br></font></div><div style=3D"font-family:arial,helve=
tica,sans-serif"><u>Closing thoughts and tiny checksum nitpick:=C2=A0</u></=
div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif">=C2=A0 =C2=A0 =C2=A0 - The m=
ultiple BIP39 seeds per language lend=C2=A0some similarities to BIP44 multi=
-account, so perhaps this can be an advantage, depends on how it is applied=
 in UI/UX&#39;s (compared to having one BIP39 seed regardless of language, =
for a given initial entropy).</div><div style=3D"font-family:arial,helvetic=
a,sans-serif">=C2=A0 =C2=A0 =C2=A0 - There is perhaps an opportunity to add=
 greater detail to the BIP39 spec in terms of standards/best-practices for =
computing checksum values, as some software may be hashing bits, versus has=
hing bytes, or hashing the entropy as a hex string, etc.. for a given entro=
py, which will result in different checksum values for the same &quot;valid=
&quot; mnemonic, that might not be &quot;valid&quot; in another wallet whic=
h may format the data differently before hashing to compute the checksum.=
=C2=A0</div><div style=3D"font-family:arial,helvetica,sans-serif">=C2=A0</d=
iv><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div><di=
v dir=3D"ltr" class=3D"m_-2528909876728425141gmail_signature"><div dir=3D"l=
tr"><div dir=3D"ltr"><div style=3D"font-size:12.8px;font-family:arial,helve=
tica,sans-serif"><span>Best regards,</span></div><div style=3D"font-size:12=
.8px;font-family:arial,helvetica,sans-serif"><span><br>Steven</span>=C2=A0<=
span>Hatzakis</span>=C2=A0</div><div style=3D"font-size:12.8px;font-family:=
arial,helvetica,sans-serif"><br></div><div style=3D"font-size:12.8px;font-f=
amily:arial,helvetica,sans-serif"><div style=3D"font-family:arial,helvetica=
,sans-serif">_______________</div><div style=3D"font-family:arial,helvetica=
,sans-serif"></div></div><h1 style=3D"color:rgb(0,0,0);font-family:Times">[=
bitcoin-dev] BIP- &amp; SLIP-0039 -- better multi-language support</h1><b s=
tyle=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">Weiji Guo</b><=
span style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">=C2=A0</=
span><a href=3D"mailto:bitcoin-dev%40lists.linuxfoundation.org?Subject=3DRe=
:%20Re%3A%20%5Bbitcoin-dev%5D%20%20BIP-%20%26%20SLIP-0039%20--%20better%20m=
ulti-language%20support&amp;In-Reply-To=3D%3CCA%2Bydi%3DLM%2Bq-9WKewb%3D65t=
WCqM1cPMoWEeWq5XAxdqg4rz%3DZJ6g%40mail.gmail.com%3E" title=3D"[bitcoin-dev]=
  BIP- &amp; SLIP-0039 -- better multi-language support" style=3D"font-fami=
ly:Times;font-size:medium" target=3D"_blank">weiji.g at gmail.com=C2=A0</a>=
<br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"><i style=
=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">Tue Nov 6 16:16:41=
 UTC 2018</i><span style=3D"color:rgb(0,0,0);font-family:Times;font-size:me=
dium"></span><p style=3D"color:rgb(0,0,0);font-family:Times;font-size:mediu=
m"></p><ul style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"><l=
i>Previous message:=C2=A0<a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2018-November/016469.html" target=3D"_blank">[bitcoin-dev]=
 draft proposal: change forwarding (improved fungibility through wallet int=
eroperability)</a></li><li>Next message:=C2=A0<a href=3D"https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2018-November/016470.html" target=3D"=
_blank">[bitcoin-dev] Considering starting a toy full-node implementation.	=
Any advice?</a></li><li><b>Messages sorted by:</b>=C2=A0<a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/date.html#164=
68" target=3D"_blank">[ date ]</a>=C2=A0<a href=3D"https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2018-November/thread.html#16468" target=3D"=
_blank">[ thread ]</a>=C2=A0<a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2018-November/subject.html#16468" target=3D"_blank">[ s=
ubject ]</a>=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2018-November/author.html#16468" target=3D"_blank">[ author ]</a>=
</li></ul><hr style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"=
><pre style=3D"white-space:pre-wrap;color:rgb(0,0,0)">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-0039
entropy, as is shown below, depends on which language to generate the
mnemonic sentence:

   Entropy &lt;=3D&gt; Mnemonic Sentence =3D&gt; PBKDF2 =3D&gt; BIP-0032 Se=
ed

Therefore when a user choose a non-English mnemonic code he or she is stuck
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&#39;s understandable as it aims to provide S=
SS
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 matter
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 entropy
or (pre) master secret, seed, whatever. In this way, the same seed/secret
could be displayed in English or in Chinese or other languages. Then there
could be 3rd party conversion tools to support translations in case any
wallet software or device does not support all specified languages. Now it
looks like:

   Mnemonic Sentence &lt;=3D&gt; Entropy =3D&gt; PBKDF2 =3D&gt; BIP-0032 Se=
ed

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 numbers=
.

So far I don&#39;t have a preference how this should be implemented. I&#39;=
d like
to hear from community first.

Thanks,

Weiji Guo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20181107/88677440/attachment.html" target=3D"_blank">http://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181107/88677440/=
attachment.html</a>&gt;
</pre><hr style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"><p =
style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"></p><ul style=
=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"><li>Previous messa=
ge:=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2018-November/016469.html" target=3D"_blank">[bitcoin-dev] draft proposal:=
 change forwarding (improved fungibility through wallet interoperability)</=
a></li><li>Next message:=C2=A0<a href=3D"https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2018-November/016470.html" target=3D"_blank">[bitcoin=
-dev] Considering starting a toy full-node implementation.	Any advice?</a><=
/li><li><b>Messages sorted by:</b>=C2=A0<a href=3D"https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2018-November/date.html#16468" target=3D"_b=
lank">[ date ]</a>=C2=A0<a href=3D"https://lists.linuxfoundation.org/piperm=
ail/bitcoin-dev/2018-November/thread.html#16468" target=3D"_blank">[ thread=
 ]</a>=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2018-November/subject.html#16468" target=3D"_blank">[ subject ]</a>=C2=
=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-=
November/author.html#16468" target=3D"_blank">[ author ]</a></li></ul><hr s=
tyle=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"><a href=3D"htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" style=3D"font-=
family:Times;font-size:medium" target=3D"_blank">More information about the=
 bitcoin-dev mailing list</a><br><div style=3D"font-size:12.8px;font-family=
:arial,helvetica,sans-serif"></div></div></div></div></div></div></div></di=
v></div></div></div>
</div></div>

--00000000000098e7c1057b09e141--