>  as it seems bad design to have to fix and maintain a wordlist for every language as the checksum depends on it.

From BIP39:

> The conversion of the mnemonic sentence to a binary seed is completely independent from generating the sentence. This results in rather simple code; there are no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators, allowing for flexibility in wordlists for typo detection or other purposes.
> Although using a mnemonic not generated by the algorithm described in "Generating the mnemonic" section is possible, this is not advised and software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid.

So BIP39 states "no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators" and yet at the same time one paragraph later "this is not advised and software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid"...

My interpretation of this:

1. ChecksumCheck function attempts to 1. find the wordlist 2. calculate the checksum.
2. If it fails to find the wordlist, return false
3. If the checksum doesn't match return false
4. If ChecksumCheck returns false, "issue a warning" but do not block seed generation. "We couldn't check if your phrase is correct... you're on your own"

99.99% of implementing apps interpretation: (remember, error handling for userspace is not done by the BIP39 library, but the app that uses it)

1. Run ChecksumCheck
2. If False, hard fail, do not allow seed generation.

If more apps would implement to the word of the BIP39 spec, multiple languages make sense, but since reality is no one follows the spec (/the spec is way too open to interpretation) then expecting every app to load every language is unreasonable.

Electrum actually handles BIP39 recovery the way the BIP specifies. I can restore random strings if I want, and it warns me, and I can ignore it if I wish.


Anywho. The BIP39 multi-language feature is crucial for non-English speakers especially from Asia. Maybe northern Europeans have no problem with English word spelling, but watching a normal Japanese person write down their English mnemonic is painful.

One letter at a time, worried they wrote it wrong... still make mistakes... lose money because of it.

Whereas users of Copay etc. that support Japanese wordlist write down their seed easily, and I have never heard of a Japanese newbie complaining about "but I'm writing it just how I have it written down" about their Japanese seed... only English.

Not trying to give anyone a hard time, just telling the facts: lack of localized words for recovery phrase causes more money loss than supporting it. (When push comes to shove, at the very least Electrum will always support their recovery because it lets you hash anything)

This is all anecdotal of course. Just sharing my experience evangelizing in Japan.

Thanks,
Jon


2018年11月8日(木) 21:16 SomberNight via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
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 => PBKDF2 => 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/015507.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-0039
> entropy, as is shown below, depends on which language to generate the
> mnemonic sentence:
>
> Entropy <=> Mnemonic Sentence => PBKDF2 => 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 <=> Entropy => PBKDF2 => 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.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3