Jonathan Underwood [ARCHIVE] on Nostr: ๐ Original date posted:2018-11-09 ๐ Original message:> as it seems bad design ...
๐
Original date posted:2018-11-09
๐ Original message:> 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ใใใใใณใฏ็คพ ใใผใใใใใณใคใณใชใใฃใตใผ
-----------------
ๆๅทๅใใใกใใปใผใธใใ้ใใฎๆนใฏไธ่จใฎๅ ฌ้้ตใใๅฉ็จไธใใใ
ๆ็ด: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181109/f93c2a37/attachment-0001.html>;
๐ Original message:> 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
-----------------
Jonathan Underwood
ใใใใใณใฏ็คพ ใใผใใใใใณใคใณใชใใฃใตใผ
-----------------
ๆๅทๅใใใกใใปใผใธใใ้ใใฎๆนใฏไธ่จใฎๅ ฌ้้ตใใๅฉ็จไธใใใ
ๆ็ด: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181109/f93c2a37/attachment-0001.html>;