Discussion:
BIP 39: Add language identifier strings for wordlists
(too old to reply)
nullius via bitcoin-dev
2018-01-05 13:58:37 UTC
Permalink
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"挢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국얎", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```

Per the comment at #L85 of the quoted file, I also know that for my
short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at
best—insofar 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 “concept ACKed” 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).
Sjors Provoost via bitcoin-dev
2018-01-05 16:04:10 UTC
Permalink
I’m 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.

However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.

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.

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).

A replacement for BIP-39 would be a good opportunity to produce a better English dictionary as Nic Johnson suggested a while ago:
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2

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.

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.

For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103

Sjors
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"挢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국얎", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 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 “concept ACKed” 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Sjors Provoost via bitcoin-dev
2018-01-05 17:13:23 UTC
Permalink
I don’t 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’t 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’ll have fewer wallets to choose from.

I think it’s 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
"Very few wallets support anything other than English"
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.
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.
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.
Alan
I’m 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.
However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
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.
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).
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2
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.
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.
For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
Sjors
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"挢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국얎", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 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 “concept ACKed” 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<signature.asc>
Aymeric Vitte via bitcoin-dev
2018-01-05 18:08:29 UTC
Permalink
See: https://github.com/Ayms/bitcoin-transactions/issues/3

OK, maybe it's my fault, I did not foresee this case, and now it's
working for p2sh (non segwit)

From my standpoint this just means that BIP39/44 stuff should be
eradicated (not BIP141 but see what happened...), this is of no use,
confusing people, doing dangerous things to recover

Really is it easier to save x words instead of a seed? Knowing that
people are creating several wallets not understanding that this is not
the purpose of BIP32?

Multisig wallets (like Electrum) have created a big mess too, on purpose
or no, I don't know, but multisig is for different parties involved, not
just one
Post by Sjors Provoost via bitcoin-dev
I don’t 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’t 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’ll have fewer wallets to choose from.
I think it’s 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
"Very few wallets support anything other than English"
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.
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.
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.
Alan
I’m 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.
However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
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.
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).
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2
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.
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.
For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
Sjors
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"挢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국얎", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 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 “concept ACKed” 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<signature.asc>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Aymeric Vitte via bitcoin-dev
2018-01-05 19:56:19 UTC
Permalink
No that's not, some parts of the answer might be but this related, this
just shows how people use wrongly BIP39 and subsequent BIPs (and
globally other things), misleading them, while the advantage of using it
is quite dubious compared to backing up a seed, unless you can convince
me of the contrary
Sjors, well in Electrum, validation is optional, but English only. As
for the Ledger-S, that sounds like a Ledger problem.
Aymeric, that is way off topic, did you reply to wrong email?
See: https://github.com/Ayms/bitcoin-transactions/issues/3
<https://github.com/Ayms/bitcoin-transactions/issues/3>
OK, maybe it's my fault, I did not foresee this case, and now it's
working for p2sh (non segwit)
From my standpoint this just means that BIP39/44 stuff should be
eradicated (not BIP141 but see what happened...), this is of no
use, confusing people, doing dangerous things to recover
Really is it easier to save x words instead of a seed? Knowing
that people are creating several wallets not understanding that
this is not the purpose of BIP32?
Multisig wallets (like Electrum) have created a big mess too, on
purpose or no, I don't know, but multisig is for different parties
involved, not just one
Post by Sjors Provoost via bitcoin-dev
I don’t 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’t 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’ll have fewer wallets to choose from.
I think it’s 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
"Very few wallets support anything other than English"
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.
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.
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.
Alan
I’m 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.
However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
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.
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).
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2
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.
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.
For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
<https://github.com/satoshilabs/slips/issues/103>
Sjors
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
<https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"挢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국얎", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 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 “concept ACKed” 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
<signature.asc>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
<https://github.com/Ayms/bitcoin-transactions>
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
<https://github.com/Ayms/torrent-live>
node-Tor : https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
GitHub : https://www.github.com/Ayms
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Aymeric Vitte via bitcoin-dev
2018-01-06 17:40:40 UTC
Permalink
Unfortunately, even "yourself" seems not to know what he is talking
about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and messy
is quite dubious

And maybe you should take a look at what people you are talking to are
doing before arguing stuff that you apparently don't know very well (ie
"the length of the *derived *key", not the seed), cf
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets> and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)
<https://github.com/Ayms/zcash-wallets>

But as you can notice there is a missing feature, ie to derive the
wallets from xpriv, there is a comment in the repo why I don't like some
things "Surprisingly from ~32 bytes keys BIP32 ends up with a 78 bytes
format to describe them with all the necessary information like indexes,
parent to possibly allow to revert the tree"

That's another thing I completely dislike with BIP39, it ends up with
xpriv, not the 32B seed, there are many, many, many posts in forums of
people fighting to figure out their private keys derived from bip39/44/etc

"No offence too" but please keep your advises for yourself, I indeed
don't read closely inept BIPs, and never said I did not like BIP32,
that's the contrary, I really like it

Before firing plenty of BIPs that do not fit together people maybe
should take a break and see what people are doing today (this is quite
amazing) and why they got stolen

And you seem to know very little about security, if you suspect you home
printer, then suspect you OS, your hw, etc, (you really envision to
generate a seed from a mobile device ???) writing 64 characters is not
very difficult for a human being, even easier than writing x words of y
length

See this too
https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887,
the tutorial was corrected, but basic things are still missing, an
offline version is when you disconnect from the internet, not when you
use the "offline version"  (assuming that the browser storage or other
stuff are not used...)

Re-ccing the list because again at a certain point of time the theory
should look at the reality and adapt accordingly, part of the example I
gave is off topic for this thread but globally (which could become
another thread) the message is: the bitcoin community should stop making
things complicate for people, releasing BIPs of no use just ends up with
complicating things more than it helps, people deserve to understand
what they are doing, manage their keys by their own and stop syncing
useless full nodes for every coin to sync their wallets, that's why I
made the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't do
anything about this (btw the primary intent of the tool was for myself
and you are right for once, I did not know that people could do so big
mistakes, that's not their fault, I see it now, my mistake for
underestimating this)
You're mistaken. BIP32 does not require a particular length. It
* Generate a seed byte sequence S of a chosen length (between 128
and 512 bits; 256 bits is advised) from a (P)RNG
The length of the derived key is 512 bits (= 64 bytes).
If you don't believe me, why don't you just try it? That seed will
derive the same keys as that mnemonic, it's a real example.
---------
About printing, there is a huge security risk involved in printing
anything. Networks, printers may have memory. People will print to PDF
when they don't have a printer on hand. Mobile users often can't print.
I wrote mine down, by hand, generated from an offline computer booted
with a readonly OS. 
Feel free to produce a recommendation to replace BIP39/32/44 if you
like, but it's not broken just because someone had trouble using your
tool/following your instructions. And no offence but I'd be wary using
a tool from someone who doesn't read the BIPs closely yet is so
confident about how other people are wrong.
And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
bytes as your wrote below, which probably corresponds to xprv,
which is
another misleading element of BIP39
The fact is indeed that "we should really find a way to overhaul
this
whole BIP 39 / 43/ 44 etc ad hoc mess"
Because the git example I provided is about someone that knows (to a
certain extent) what he is doing, then made a mistake for the
destination address, which is not related to this discussion
This just shows how complicate it can become even for people knowing
this to retrieve their wallet and how wallets made it "the easy
way" (ie
bip39, 44, multisig...)
If people prefer to store mnemonics, why not, but "writing down"
in both
messages above is not accurate, you would better print it and
cut it in
n pieces if you like, then the point of using mnemonics that you
can't
remember more than an hex string still remains useless from my
standpoint
Beside the theory we should look now if BIP39 & all brought more
good
than the contrary in practice, I think that the later wins
Hi Alan,
The Github issue is arguably unrelated, which is why I put it
at the end and said “some related”.
However it does all tie together; we should really find a way
to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess, ideally in
a way that even Bitcoin Core would be willing to use it. When you
change the word list, it’s best to change everything else at the
same time. Otherwise you’d have too many different standards,
which is a pain for wallets to implement.
I share your view than a mnemonic is better than a bunch of hex
numbers. It’s easier to memorize and easier to write down. Some
people don’t like it when users write down phrases, but they’re
much, much more likely to lose their coins than some burglar to
find the piece of paper. My issue is only with the way derivation
currently works.
Sjors
Op 5 jan. 2018, om 21:05 heeft Alan Evans
Taking it off the board. I can't read all of that issue.
BIP0039 mnemonic generates a seed. Everything past there to do
with addresses (BIP32/44/49/141 whatever) is the same as if you
started with the seed. So you can't blaim BIP0039 for that
person's misunderstanding, and the way different wallets use
different derivation paths.
If someone has a BIP0039 mnemonic and would rather back up the
seed, they can go ahead. But one tiny mistake in writing it down
and you may have a hell of a time finding out what's wrong as
every seed is valid. A mistake in writing down words is far harder
to make. You can also memorize a mnemonic (hence the name), the
average person cannot memorize a seed.
fork canal mad beyond spike pool expire fuel region impose
ceiling video
f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
But they lead to the same addresses.
Need I say more?
On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
No that's not, some parts of the answer might be but this
related, this just shows how people use wrongly BIP39 and
subsequent BIPs (and globally other things), misleading them,
while the advantage of using it is quite dubious compared to
backing up a seed, unless you can convince me of the contrary
Sjors, well in Electrum, validation is optional, but English
only. As for the Ledger-S, that sounds like a Ledger problem.
Aymeric, that is way off topic, did you reply to wrong email?
On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
See: https://github.com/Ayms/bitcoin-transactions/issues/3
<https://github.com/Ayms/bitcoin-transactions/issues/3>
OK, maybe it's my fault, I did not foresee this case, and now
it's working for p2sh (non segwit)
From my standpoint this just means that BIP39/44 stuff should
be eradicated (not BIP141 but see what happened...), this is of no
use, confusing people, doing dangerous things to recover
Really is it easier to save x words instead of a seed?
Knowing that people are creating several wallets not understanding
that this is not the purpose of BIP32?
Multisig wallets (like Electrum) have created a big mess too,
on purpose or no, I don't know, but multisig is for different
parties involved, not just one
Post by Sjors Provoost via bitcoin-dev
I don’t know about Electrum but many wallets validate the
English words, which helps in catching typos.
Post by Sjors Provoost via bitcoin-dev
Hardware wallets without a full keyboard, like the Ledger
Nano S, won’t even let you freely type characters; you have to
select words from a list.
Post by Sjors Provoost via bitcoin-dev
So although the standard technically allows what you say, if
you use anything other than 12, 16 or 24 English words, you’ll
have fewer wallets to choose from.
Post by Sjors Provoost via bitcoin-dev
I think it’s better to come up with a new standard than
trying to patch BIP-39 at this point, which is why I brought it up.
Post by Sjors Provoost via bitcoin-dev
Sjors
Op 5 jan. 2018, om 17:27 heeft Alan Evans
"Very few wallets support anything other than English"
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
Alan
On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev
I’m 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.
Post by Sjors Provoost via bitcoin-dev
However, because people can memorize things better in their
native tongue, supporting multiple languages seems quite useful.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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).
Post by Sjors Provoost via bitcoin-dev
A replacement for BIP-39 would be a good opportunity to
produce a better English dictionary as Nic Johnson suggested a
Post by Sjors Provoost via bitcoin-dev
         • all words are 4-8 characters
         • all 4-character prefixes are unique (very useful
for hardware wallets)
Post by Sjors Provoost via bitcoin-dev
         • no two words have edit distance < 2
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
https://github.com/satoshilabs/slips/issues/103
<https://github.com/satoshilabs/slips/issues/103>
Post by Sjors Provoost via bitcoin-dev
Sjors
Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
<https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
Post by Sjors Provoost via bitcoin-dev
```
       LANG(english,                   u8"English",   
"en",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(chinese_simplified,        u8"汉语",
"zh-CN",ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(chinese_traditional,       u8"挢語",
"zh-TW",ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(french,                    u8"Français", 
 "fr",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(italian,                   u8"Italiano", 
 "it",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(japanese,                  u8"日本語",       
"ja",   u8"\u3000"  ),
Post by Sjors Provoost via bitcoin-dev
       LANG(korean,                    u8"한국얎",       
"ko",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(spanish,                   u8"Español",   
"es",   ascii_space )
Post by Sjors Provoost via bitcoin-dev
```
Per the comment at #L85 of the quoted file, I also know
that for my short identifiers for Chinese, “zh-CN” and “zh-TW”,
are imprecise at best—insofar 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?
Post by Sjors Provoost via bitcoin-dev
My general suggestion is that the specification of
appropriate strings in
Post by Sjors Provoost via bitcoin-dev
bitcoin:bips/bip-0039/bip-0039-wordlists.md
<http://bip-0039-wordlists.md>
Post by Sjors Provoost via bitcoin-dev
  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.
Post by Sjors Provoost via bitcoin-dev
Should this proposal be “concept ACKed” 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.
Post by Sjors Provoost via bitcoin-dev
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).
Post by Sjors Provoost via bitcoin-dev
______________________________
_________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
Post by Sjors Provoost via bitcoin-dev
______________________________
_________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
Post by Sjors Provoost via bitcoin-dev
<signature.asc>
______________________________
_________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
https://github.com/Ayms/bitcoin-transactions
<https://github.com/Ayms/bitcoin-transactions>
https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
http://peersm.com/getblocklist
http://peersm.com/findmyass
http://torrent-live.org
http://www.peersm.com
https://github.com/Ayms/torrent-live
<https://github.com/Ayms/torrent-live>
https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
https://www.github.com/Ayms
--
https://github.com/Ayms/bitcoin-transactions
<https://github.com/Ayms/bitcoin-transactions>
https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
http://peersm.com/getblocklist
http://peersm.com/findmyass
http://torrent-live.org
http://www.peersm.com
https://github.com/Ayms/torrent-live
<https://github.com/Ayms/torrent-live>
https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
https://www.github.com/Ayms
--
https://github.com/Ayms/bitcoin-transactions
<https://github.com/Ayms/bitcoin-transactions>
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
GitHub : https://www.github.com/Ayms
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Aymeric Vitte via bitcoin-dev
2018-01-06 19:46:43 UTC
Permalink
Calm down now and stop your "do you want a" or "link" stupid comments,
whether you are really willing to propose some improvements, whether you
are just posting for nothing

BIP39:

"The length of the derived key is 512 bits (= 64 bytes).

This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods."

So the derived key is the seed? (derived key... this seed, really?
"similar methods",funny) That's not clear, then why everybody is using
xpriv which corresponds to the first step of the derivation (ie the
derived key)? And why BIP39 does not follow BIP32 recommendation (32B seed)?

Anyway, I don't really care about this stuff in fact, the only
interesting thing in this discussion beside arguing around unclear specs
misleading many people would be if you can convince that BIP39 & co are
really usefull for people (and easier than writing a seed): what
feedback do you have, don't you see how it's a pain in the xss for
everybody?

And if the answer is positive how can you can make it easier for people
(I am amazed too that people know about BIPXYZ, they should not),
probably this discussion will bore people and get moderated, but as
mentioned below, even maybe off topic, the subject is wider
Post by Aymeric Vitte via bitcoin-dev
 Unfortunately, even "yourself" seems not to know what he is talking
about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and
messy is quite dubious
And yet you still fail to read the BIP, do you want a
link? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki I
between 128 and 512 bits
So, that's between 16 and 64 bytes, the advisory of 256 is clearly a
minimum.
 That's another thing I completely dislike with BIP39, it ends up
with xpriv, not the 32B seed
Please also read
BIP0039 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki,
it generates *a BIP32 seed only*, no xpriv, that's completely false,
then you use BIP0032 as normal with the seed. Because BIP0039 produces
a seed, your whole argument goes out of the window, you can write the
seed if that's what you want to do, and throw away the mnemonic.
Unfortunately, even "yourself" seems not to know what he is
talking about (so imagine for other people, 256 bits is advised
--> 32B), probably that's why you brought this discussion off the
list, then making recommendations to improve something that is
misleading and messy is quite dubious
And maybe you should take a look at what people you are talking to
are doing before arguing stuff that you apparently don't know very
well (ie "the length of the *derived *key", not the seed), cf
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets> and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)
<https://github.com/Ayms/zcash-wallets>
But as you can notice there is a missing feature, ie to derive the
wallets from xpriv, there is a comment in the repo why I don't
like some things "Surprisingly from ~32 bytes keys BIP32 ends up
with a 78 bytes format to describe them with all the necessary
information like indexes, parent to possibly allow to revert the tree"
That's another thing I completely dislike with BIP39, it ends up
with xpriv, not the 32B seed, there are many, many, many posts in
forums of people fighting to figure out their private keys derived
from bip39/44/etc
"No offence too" but please keep your advises for yourself, I
indeed don't read closely inept BIPs, and never said I did not
like BIP32, that's the contrary, I really like it
Before firing plenty of BIPs that do not fit together people maybe
should take a break and see what people are doing today (this is
quite amazing) and why they got stolen
And you seem to know very little about security, if you suspect
you home printer, then suspect you OS, your hw, etc, (you really
envision to generate a seed from a mobile device ???) writing 64
characters is not very difficult for a human being, even easier
than writing x words of y length
See this too
https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887
<https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887>,
the tutorial was corrected, but basic things are still missing, an
offline version is when you disconnect from the internet, not when
you use the "offline version"  (assuming that the browser storage
or other stuff are not used...)
Re-ccing the list because again at a certain point of time the
theory should look at the reality and adapt accordingly, part of
the example I gave is off topic for this thread but globally
(which could become another thread) the message is: the bitcoin
community should stop making things complicate for people,
releasing BIPs of no use just ends up with complicating things
more than it helps, people deserve to understand what they are
doing, manage their keys by their own and stop syncing useless
full nodes for every coin to sync their wallets, that's why I made
the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't
do anything about this (btw the primary intent of the tool was for
myself and you are right for once, I did not know that people
could do so big mistakes, that's not their fault, I see it now, my
mistake for underestimating this)
You're mistaken. BIP32 does not require a particular length. It
* Generate a seed byte sequence S of a chosen length (between
128 and 512 bits; 256 bits is advised) from a (P)RNG
The length of the derived key is 512 bits (= 64 bytes).
If you don't believe me, why don't you just try it? That seed
will derive the same keys as that mnemonic, it's a real example.
---------
About printing, there is a huge security risk involved in
printing anything. Networks, printers may have memory. People
will print to PDF when they don't have a printer on hand. Mobile
users often can't print.
I wrote mine down, by hand, generated from an offline computer
booted with a readonly OS. 
Feel free to produce a recommendation to replace BIP39/32/44 if
you like, but it's not broken just because someone had trouble
using your tool/following your instructions. And no offence but
I'd be wary using a tool from someone who doesn't read the BIPs
closely yet is so confident about how other people are wrong.
On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte
And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
bytes as your wrote below, which probably corresponds to
xprv, which is
another misleading element of BIP39
The fact is indeed that "we should really find a way to
overhaul this
whole BIP 39 / 43/ 44 etc ad hoc mess"
Because the git example I provided is about someone that
knows (to a
certain extent) what he is doing, then made a mistake for the
destination address, which is not related to this discussion
This just shows how complicate it can become even for
people knowing
this to retrieve their wallet and how wallets made it "the
easy way" (ie
bip39, 44, multisig...)
If people prefer to store mnemonics, why not, but "writing
down" in both
messages above is not accurate, you would better print it
and cut it in
n pieces if you like, then the point of using mnemonics
that you can't
remember more than an hex string still remains useless from
my standpoint
Beside the theory we should look now if BIP39 & all brought
more good
than the contrary in practice, I think that the later wins
Hi Alan,
The Github issue is arguably unrelated, which is why I put
it at the end and said “some related”.
However it does all tie together; we should really find a
way to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess,
ideally in a way that even Bitcoin Core would be willing to
use it. When you change the word list, it’s best to change
everything else at the same time. Otherwise you’d have too
many different standards, which is a pain for wallets to
implement.
I share your view than a mnemonic is better than a bunch
of hex numbers. It’s easier to memorize and easier to write
down. Some people don’t like it when users write down
phrases, but they’re much, much more likely to lose their
coins than some burglar to find the piece of paper. My issue
is only with the way derivation currently works.
Sjors
Op 5 jan. 2018, om 21:05 heeft Alan Evans
Taking it off the board. I can't read all of that issue.
BIP0039 mnemonic generates a seed. Everything past there to
do with addresses (BIP32/44/49/141 whatever) is the same as
if you started with the seed. So you can't blaim BIP0039 for
that person's misunderstanding, and the way different wallets
use different derivation paths.
If someone has a BIP0039 mnemonic and would rather back
up the seed, they can go ahead. But one tiny mistake in
writing it down and you may have a hell of a time finding out
what's wrong as every seed is valid. A mistake in writing
down words is far harder to make. You can also memorize a
mnemonic (hence the name), the average person cannot memorize
a seed.
fork canal mad beyond spike pool expire fuel region
impose ceiling video
f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
But they lead to the same addresses.
Need I say more?
On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
No that's not, some parts of the answer might be but this
related, this just shows how people use wrongly BIP39 and
subsequent BIPs (and globally other things), misleading them,
while the advantage of using it is quite dubious compared to
backing up a seed, unless you can convince me of the contrary
Sjors, well in Electrum, validation is optional, but
English only. As for the Ledger-S, that sounds like a Ledger
problem.
Aymeric, that is way off topic, did you reply to wrong
email?
On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
https://github.com/Ayms/bitcoin-transactions/issues/3
<https://github.com/Ayms/bitcoin-transactions/issues/3>
OK, maybe it's my fault, I did not foresee this case,
and now it's working for p2sh (non segwit)
From my standpoint this just means that BIP39/44 stuff
should be eradicated (not BIP141 but see what happened...),
this is of no use, confusing people, doing dangerous things
to recover
Really is it easier to save x words instead of a seed?
Knowing that people are creating several wallets not
understanding that this is not the purpose of BIP32?
Multisig wallets (like Electrum) have created a big mess
too, on purpose or no, I don't know, but multisig is for
different parties involved, not just one
Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a
Post by Sjors Provoost via bitcoin-dev
I don’t know about Electrum but many wallets validate
the English words, which helps in catching typos.
Post by Sjors Provoost via bitcoin-dev
Hardware wallets without a full keyboard, like the
Ledger Nano S, won’t even let you freely type characters; you
have to select words from a list.
Post by Sjors Provoost via bitcoin-dev
So although the standard technically allows what you
say, if you use anything other than 12, 16 or 24 English
words, you’ll have fewer wallets to choose from.
Post by Sjors Provoost via bitcoin-dev
I think it’s better to come up with a new standard than
trying to patch BIP-39 at this point, which is why I brought it up.
Post by Sjors Provoost via bitcoin-dev
Sjors
Op 5 jan. 2018, om 17:27 heeft Alan Evans
"Very few wallets support anything other than English"
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
Alan
On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via
bitcoin-dev
Post by Sjors Provoost via bitcoin-dev
I’m 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.
Post by Sjors Provoost via bitcoin-dev
However, because people can memorize things better in
their native tongue, supporting multiple languages seems
quite useful.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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).
Post by Sjors Provoost via bitcoin-dev
A replacement for BIP-39 would be a good opportunity
to produce a better English dictionary as Nic Johnson
Post by Sjors Provoost via bitcoin-dev
         • all words are 4-8 characters
         • all 4-character prefixes are unique (very
useful for hardware wallets)
Post by Sjors Provoost via bitcoin-dev
         • no two words have edit distance < 2
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
https://github.com/satoshilabs/slips/issues/103
<https://github.com/satoshilabs/slips/issues/103>
Post by Sjors Provoost via bitcoin-dev
Sjors
Op 5 jan. 2018, om 14:58 heeft nullius via
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.
Post by Sjors Provoost via bitcoin-dev
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.
Post by Sjors Provoost via bitcoin-dev
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/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
<https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
Post by Sjors Provoost via bitcoin-dev
```
       LANG(english,                   u8"English",   
"en",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(chinese_simplified,        u8"汉语",
"zh-CN",ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(chinese_traditional,       u8"挢語",
"zh-TW",ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(french,                    u8"Français", 
 "fr",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(italian,                   u8"Italiano", 
 "it",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(japanese,                  u8"日本語",       
"ja",   u8"\u3000"  ),
Post by Sjors Provoost via bitcoin-dev
       LANG(korean,                    u8"한국얎",       
"ko",   ascii_space ),
Post by Sjors Provoost via bitcoin-dev
       LANG(spanish,                   u8"Español",   
"es",   ascii_space )
Post by Sjors Provoost via bitcoin-dev
```
Per the comment at #L85 of the quoted file, I also
know that for my short identifiers for Chinese, “zh-CN” and
“zh-TW”, are imprecise at best—insofar 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?
Post by Sjors Provoost via bitcoin-dev
My general suggestion is that the specification of
appropriate strings in
Post by Sjors Provoost via bitcoin-dev
bitcoin:bips/bip-0039/bip-0039-wordlists.md
<http://bip-0039-wordlists.md>
Post by Sjors Provoost via bitcoin-dev
  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.
Post by Sjors Provoost via bitcoin-dev
Should this proposal be “concept ACKed” 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.
Post by Sjors Provoost via bitcoin-dev
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).
Post by Sjors Provoost via bitcoin-dev
______________________________
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
nullius via bitcoin-dev
2018-01-05 18:08:50 UTC
Permalink
Post by Sjors Provoost via bitcoin-dev
I’m 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.
However, because people can memorize things better in their native
tongue, supporting multiple languages seems quite useful.
I would prefer a new standard [...] A replacement for BIP-39 [...]
[snip]
https://github.com/satoshilabs/slips/issues/103
You present some interesting ideas; and I will be much interested in the
Github issue you referenced—thanks for that. However, this discussion
is *far* beyond the scope of my simple proposal and request to add
standardized native language and short-ASCII identifier strings to the
BIP repository. I suggest that readers solely interested in the
existing BIP 39 standard and its direct application to Bitcoin should
stop reading right here.

----

That being said, I should briefly address some of the issues you raise
(with further discussion best continued elsewhere):

I *strongly* urge the importance of language-specific standardized
wordlists. Even an individual who has secondarily acquired reasonable
fluency in English will most likely have the least difficulty
memorizing, transcribing, and otherwise handling a “mother-tongue”
mnemonic. Such an advantage is important in applications whereby even
slight errors can be fatal, and every bit counts. This is to say
nothing of persons who have limited or no English-language knowledge.

Yet for multiple reasons, multilanguage support is only feasible with
standardization. Wordlist creation is a highly specialized task.
Independent implementation of standards is imperative for avoiding
implementation lock-in; and independent implementors (such as I) would
be unable to create sets multi-language wordlists on their own, anyway.
For a view of the language-specific process involved in creating a
wordlist, I invite everybody following this discussion to review BIP
repository PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both
variants); #152 (French); #306 (Italian); #544 (Korean, rejected); and
#570 (Korean). The rejection of #544 for Korean, and its superseding
with #570 is particularly instructive.

With standardized wordlists, independent implementation is easy. In my
own implementation, the language switching backend (excluding the UI[1])
for multilingual mnemonic generation required only relatively small C
code changes, as seen here[0]:

[0] https://github.com/nym-zone/easyseed/commit/5b6a6668458d96d6ccc4bf19e4fd40fe6ea72fec#diff-20dcf1782b7568b85ea01ed695abeb02

[1] https://github.com/nym-zone/easyseed/commit/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6#diff-20dcf1782b7568b85ea01ed695abeb02

Admittedly, the multilingual requirements for seed generation will take
a bit more; and my nonstandard, non-BIP39 ideas which require decoding
words directly back to bits will take yet more. But it is still not
problematic.

I only began writing this tool one week ago, as of today; and it has
been a side project requiring small amounts of time, not a full-time
dedicated task. When I fully complete all aspects of seed generation,
then users will have the option of another simple open-source tool which
*will* be able to output a binary or BIP-32-formatted (“xprv”) 512-bit
seed, given input of an existing mnemonic in any language supported by
official BIP 39 wordlists. Output can then be imported to any wallet
software which supports BIP 32, regardless of the wallet’s langauge
support (and whether or not the wallet supports BIP 39 at all).

**The ease of creating such tools squarely answers your concerns about
vendor lock-in.** And yes, it’s easy. I can attest as a lone coder,
it’s easy for me to create “easyseed” as a side project!

Finally, aside: In the discussion at SLIP repository issue #103, I see
mention of m-of-n SSSS. I have been mentally whiteboarding just such an
application involving mnemonics. Watch for it. <g> It is likely that
I will crib the BIP 39 wordlists, given the impossibility that I could
create my own set of wordlists in many languages. I only wish that the
BIP repository had support for more languages. More! Adding each new
language to my implementation(s) will require approximately one-line
code changes for me.

(Aside further: Why is there not a Dutch wordlist? I should like to
add that, please—meneer Provoost. More wordlists!)

Aside still yet further: Should you be interested in more general
applications of mnemonic phrases for pseudorandom strings, I think you
will like this future feature which currently exists only as an Easter
egg, (un)documented in my commit log:

https://github.com/nym-zone/easyseed/commit/ba77be1b1a1f0c6af50ceba5c89f4adece7e5dff

Further discussion is invited by private mail, in an appropriate public
venue, or otherwise not on a bitcoin-dev thread which makes a simple
request and proposal as to the existing BIP 39 standard—thanks.
--
***@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
Pavol Rusnak via bitcoin-dev
2018-01-07 15:16:47 UTC
Permalink
Post by nullius via bitcoin-dev
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.
I am advising not to use any other language than English for BIP39. I
got persuaded to allow more languages when writing BIP39 spec, but I
learned that it was something I should've been more persistently against.

I am currently drafting a new standard[1] which will allow also Shamir
Secret Scheme Splitting and there we disallow usage of a custom wordlist
in order to eradicate this mess. Will try to push this as BIP too once
we get it to the point we are OK with the contents.

https://github.com/satoshilabs/slips/blob/master/slip-0039.md
--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
木ノ下じょな via bitcoin-dev
2018-01-08 07:35:52 UTC
Permalink
This is very sad.

The number one problem in Japan with BIP39 seeds is with English words.

I have seen a 60 year old Japanese man writing down his phrase (because he
kept on failing recovery), and watched him write down "aneter" for
"amateur"...
So instead I had him use Copay which generates Japanese words, wrote it
down 20x faster, and perfectly. Was able to recovery on the first try.
Imagine if I didn't tell him to try recovery before using it? (iirc Trezor
doesn't say to wipe and recover before using???)

If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
Even native English speakers who can't spell can mess it up badly too.

To be honest, a key storage format that doesn't support multiple languages
is much more dangerous than any doomsday situation you can think of for
supporting them.

BIP39 states that seed derivation is INDEPENDENT of wordlists, and that
failure to verify checksum (not knowing the wordlist falls under this)
should "WARN" the user and not fail, continuing to derive the seed anyways.
Currently the only wallet I know of following this part of the BIP is,
ironically Electrum. I can recover any BIP39 phrase from any wordlist even
if Electrum doesn't know it.

I really hope you reconsider multi-language support for everything moving
forward.

I understand it's a nightmare to plan for and support, which is fine if you
were just developing a piece of software sold by a company based in a
western country... but you are trying to make a standard for an
international currency. Defining "everyone should only use English, because
ASCII is easier to plan for" is not a good way to move forward as a
currency.

I am just thinking of all the users I will have to help out down the road
when they come crying to me saying they can't recover, and it turns out
they wrote down some non-English gibberish in roman characters claiming "I
wrote the English just as it was on the screen!" and I have to write a
brute force script to try all the word combinations for the mystery words.
(I have done this before)

Just my two cents. Not to be accusatory or anything.
Please reconsider. Thanks.

2018-01-08 0:16 GMT+09:00 Pavol Rusnak via bitcoin-dev <
Post by Pavol Rusnak via bitcoin-dev
Post by nullius via bitcoin-dev
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.
I am advising not to use any other language than English for BIP39. I
got persuaded to allow more languages when writing BIP39 spec, but I
learned that it was something I should've been more persistently against.
I am currently drafting a new standard[1] which will allow also Shamir
Secret Scheme Splitting and there we disallow usage of a custom wordlist
in order to eradicate this mess. Will try to push this as BIP too once
we get it to the point we are OK with the contents.
https://github.com/satoshilabs/slips/blob/master/slip-0039.md
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: http://openpgpjs.org

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-----END PGP PUBLIC KEY BLOCK-----
nullius via bitcoin-dev
2018-01-08 11:13:28 UTC
Permalink
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase (because
he kept on failing recovery), and watched him write down "aneter" for
"amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.

I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
down—then later, type it back in:

すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀

(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)

No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
savings on your ability to handwrite *this*:

にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ

Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.

----

If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then
think of how much money would be lost by your non-Japanese-literate
family and friends—if BIP 39 had only Japanese wordlists, and your folks
needed to wrestle with the above phrases as their “mnemonics”.

In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings.
The Japanese man in the quoted story, who wrote “aneter” for “amateur”,
was not dealing with a *mnemonic*: He was using the world’s most
inefficient means of making cryptic bitstrings *less* userfriendly.

----

I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?

I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak
all these different languages; and I want to implement them all. *All.*

Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.

Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of
“English only!”

Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially
restricted to English. I am fortunate; for as of this moment, we have a
standard called “BIP 39” which has seven non-English wordlists, and four
more pending in open pull requests (#432, #442, #493, #621).

I request discussion of language identification strings appropriate for
use with that standard.

(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should
go without saying, easyseed output the Japanese perfectly!)
--
***@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
Greg Sanders via bitcoin-dev
2018-01-08 14:34:39 UTC
Permalink
Has anyone actually used the multilingual support in bip39?

If a feature of the standard has not been(widely?) used in years, and isn't
supported in any major wallet(?), it seems indicative it was a mistake to
add it in the first place, since it's a footgun in the making for some poor
sap who can't even read English letters when almost all documentation is
written in English.

On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase (because
he kept on failing recovery), and watched him write down "aneter" for
"amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please, let’s
put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking about
a Trezor; so now, hey you there, stake the backup of your life’s savings on
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
dealing with a *mnemonic*: He was using the world’s most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an appropriate
string for identifying the Japanese language to Japanese users? And what
of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the greatest
guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism of
multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of “English only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing. I
have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Greg Sanders via bitcoin-dev
2018-01-08 14:54:38 UTC
Permalink
Let me re-phrase: Is it a known thing for users to actually use it?
On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?
Copay (and all its clones) use it.
Post by Greg Sanders via bitcoin-dev
If a feature of the standard has not been(widely?) used in years, and
isn't supported in any major wallet(?), it seems indicative it was a
mistake to add it in the first place, since it's a footgun in the making
for some poor sap who can't even read English letters when almost all
documentation is written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
Post by nullius via bitcoin-dev
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase (because
he kept on failing recovery), and watched him write down "aneter" for
"amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
dealing with a *mnemonic*: He was using the world’s most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of “English only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
Matias Alejo Garcia via bitcoin-dev
2018-01-08 15:23:53 UTC
Permalink
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new languages
in BIP39.
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?
Copay (and all its clones) use it.
Post by Greg Sanders via bitcoin-dev
If a feature of the standard has not been(widely?) used in years, and
isn't supported in any major wallet(?), it seems indicative it was a
mistake to add it in the first place, since it's a footgun in the making
for some poor sap who can't even read English letters when almost all
documentation is written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
Post by nullius via bitcoin-dev
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
dealing with a *mnemonic*: He was using the world’s most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of “English only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
AJ West via bitcoin-dev
2018-01-08 15:26:38 UTC
Permalink
Greg yes, there were already examples in this very thread of people
explaining how they use languages other than English. I'm shocked that so
many people are resisting the idea that just *maybe* there could be people
in other parts of the world who do not want to use or cannot use the strict
set of latin characters and words from the English language.

I agree with Sjors and maybe I'm simplifying too much, but can't we just
map an existing ISO/UTF language character standard to the seeds? Why is
there a word list at all? Choose a flexible encoding standard, create a
clever map to the bytes, make sure to include a checksum.

As an aside, I know there are some conventions which add space for error
correction but I personally don't love the idea of somebody inputting what
they think is the proper seed, only to have it auto-corrected and thus
reinforcing their erroneously saved/written seed backup.

Pavol, why do you say "I learned that it was something I should've been
more persistently against?" I still can't see any good arguments as to why
we should limit this to English other than "It's easier to support a single
language" which comes at the cost of "It's hard for me to backup my seed"
for those who don't speak English.

On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
Post by Matias Alejo Garcia via bitcoin-dev
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new
languages in BIP39.
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?
Copay (and all its clones) use it.
Post by Greg Sanders via bitcoin-dev
If a feature of the standard has not been(widely?) used in years, and
isn't supported in any major wallet(?), it seems indicative it was a
mistake to add it in the first place, since it's a footgun in the making
for some poor sap who can't even read English letters when almost all
documentation is written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
Post by nullius via bitcoin-dev
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier
to plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
dealing with a *mnemonic*: He was using the world’s most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into
criticism of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of “English
only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate
for use with that standard.
(P.S., I hope that my system did not mangle anything in the
foregoing. I have seen weird copypaste behaviour mess up decomposed
characters. I thought of this after I searched for and collected some
visually fascinating phrases; so I tried to normalize these to NFC... It
should go without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Greg Sanders via bitcoin-dev
2018-01-08 15:32:58 UTC
Permalink
I'm shocked that so many people are resisting the idea that just *maybe* there
could be people in other parts of the world who do not want to use or
cannot use the strict set of latin characters and words from the English
language.


You're mistaking concern for users potentially losing money with disdain
for them. I can read a few languages, yet I would not advise users to use a
wordlist that might not have support across multiple wallet
implementations, resulting in lock-in or worse.

If I'm wrong, great, more people can use software strictly in their native
language in a safe manner!
Greg yes, there were already examples in this very thread of people
explaining how they use languages other than English. I'm shocked that so
many people are resisting the idea that just *maybe* there could be
people in other parts of the world who do not want to use or cannot use the
strict set of latin characters and words from the English language.
I agree with Sjors and maybe I'm simplifying too much, but can't we just
map an existing ISO/UTF language character standard to the seeds? Why is
there a word list at all? Choose a flexible encoding standard, create a
clever map to the bytes, make sure to include a checksum.
As an aside, I know there are some conventions which add space for error
correction but I personally don't love the idea of somebody inputting what
they think is the proper seed, only to have it auto-corrected and thus
reinforcing their erroneously saved/written seed backup.
Pavol, why do you say "I learned that it was something I should've been
more persistently against?" I still can't see any good arguments as to why
we should limit this to English other than "It's easier to support a single
language" which comes at the cost of "It's hard for me to backup my seed"
for those who don't speak English.
On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
Post by Matias Alejo Garcia via bitcoin-dev
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new
languages in BIP39.
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?
Copay (and all its clones) use it.
Post by Greg Sanders via bitcoin-dev
If a feature of the standard has not been(widely?) used in years, and
isn't supported in any major wallet(?), it seems indicative it was a
mistake to add it in the first place, since it's a footgun in the making
for some poor sap who can't even read English letters when almost all
documentation is written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
Post by nullius via bitcoin-dev
Post by 木ノ下じょな via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier
to plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to
entrust *their own money* to their abilities to very, very carefully write
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
dealing with a *mnemonic*: He was using the world’s most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into
criticism of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of “English
only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate
for use with that standard.
(P.S., I hope that my system did not mangle anything in the
foregoing. I have seen weird copypaste behaviour mess up decomposed
characters. I thought of this after I searched for and collected some
visually fascinating phrases; so I tried to normalize these to NFC... It
should go without saying, easyseed output the Japanese perfectly!)
--
591B2F307E0C
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Aymeric Vitte via bitcoin-dev
2018-01-08 16:02:02 UTC
Permalink
That's the point indeed and the scope is wider than XYZIP-39, even if
what I mean is the very contrary of your point (really bitcoin is
reserved to an elite understanding english/ascii letters?)

This proposal is tailor made for Trezor and does not simplify anything
for people, that's the contrary again

As I suggested in another response to this thread (which was moderated
due probably to some uninteresting parts of the discussion) it's time to
take a break and really make a survey worldwide of what people need,
what they understand and what they need to secure their coins, nobody
has any feedback about this (and maybe does not even care)

Wallets created a big mess implementing non standard things (or things
they thought standard but that are not), or things not intended for the
final use, or things that people can't understand, it's time to correct
this, unless wallets want to keep people tied forever to them (when I
read Trezor or other wallets docs, it's quite misleading, "sending coins
to your wallet", what does it mean? Nothing, and people think it means
something, this should stop now)

And again, I don't see the point of wordlist (in addition in a language
that they don't understand) compared to backing up a 32B hex string
(that you can encrypt different ways at different places), assuming that
the hex format can be made available in all languages

"yet I would not advise users to use a wordlist that might not have
support across multiple wallet implementations, resulting in lock-in or
worse"--> this single sentence shows how the whole model is wrong and
how you think that you can lock people
Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?
On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?
Copay (and all its clones) use it. 
 
If a feature of the standard has not been(widely?) used in
years, and isn't supported in any major wallet(?), it seems
indicative it was a mistake to add it in the first place,
since it's a footgun in the making for some poor sap who can't
even read English letters when almost all documentation is
written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev
On 2018-01-08 at 07:35:52 +0000, 朚ノ䞋じょな
This is very sad.
The number one problem in Japan with BIP39 seeds is
with English words.
I have seen a 60 year old Japanese man writing down
his phrase (because he kept on failing recovery), and
watched him write down "aneter" for "amateur"...
[...]
If you understand English and can spell, you read a
word, your brain processes the word, and you can spell
it on your own when writing down.  Not many Japanese
people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on
occasion.
[...]
Defining "everyone should only use English, because
ASCII is easier to plan for" is not a good way to move
forward as a currency.
Well said.  Thank you for telling of these experiences. 
Now please, let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic
standard to entrust *their own money* to their abilities
to very, very carefully write this down—then later, type
すさん たんろ りゆう しもん おいおん しずう
ずこや はやい おうさた ほくろ けちゃっふ たも぀
(Approximate translation:  “Whatever would you do if
Bitcoin had been invented by somebody named Satoshi
Nakamoto?”)
No, wait:  That is only a 12-word mnemonic.  We are
probably talking about a Trezor; so now, hey you there,
stake the backup of your life’s savings on your ability to
にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
ずうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
ぞこむ すひょう おやゆひ ふせく けさき めいきょく こんたけ
Ready to bet your money on *that* as a backup phrase in
your own hands?  No?  Then please, stop demanding that
others risk *their* money on the inverse case.
----
If you cheat here by having studied Japanese, then
remember that many Japanese people know English and other
European languages, too.  Then think of how much money
would be lost by your non-Japanese-literate family and
friends—if BIP 39 had only Japanese wordlists, and your
folks needed to wrestle with the above phrases as their
“mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at
all.  A “mnemonic” implies aid to memory.  Gibberish in a
wholly alien writing system is much worse even than
transcribing pseudorandom hex strings.  The Japanese man
in the quoted story, who wrote “aneter” for “amateur”, was
not dealing with a *mnemonic*:  He was using the world’s
most inefficient means of making cryptic bitstrings *less*
userfriendly.
----
I began this thread with a quite simple request:  Is “日本語”
an appropriate string for identifying the Japanese
language to Japanese users?  And what of the other strings
I posted for other languages?
I asked this as an implementer working on my own instance
of the greatest guard against vendor lock-in and stale
software:  Independent implementations.  —  I asked,
because obviously, I myself do not speak all these
different languages; and I want to implement them all.  *All.*
Some replies have been interesting in their own right; but
thus far, nobody has squarely addressed the substance of
my question.
Most worrisome is that much of the discussion has veered
into criticism of multi-language support.  I opened with a
question about other languages, and I am getting replies
which raise a hue and cry of “English only!”
Though I am fluent and literate in English, I am
uninterested in ever implementing any standard of this
nature which is artificially restricted to English.  I am
fortunate; for as of this moment, we have a standard
called “BIP 39” which has seven non-English wordlists, and
four more pending in open pull requests (#432, #442, #493,
#621).
I request discussion of language identification strings
appropriate for use with that standard.
(P.S., I hope that my system did not mangle anything in
the foregoing.  I have seen weird copypaste behaviour mess
up decomposed characters.  I thought of this after I
searched for and collected some visually fascinating
phrases; so I tried to normalize these to NFC...  It
should go without saying, easyseed output the Japanese
perfectly!)
--
0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h |
0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to
hide.’
No!  Because I do nothing wrong, I have nothing to show.”
— nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Loading...