[bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[nullius]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Sjors Provoost]

[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]

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

> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Sjors Provoost]

[-- Attachment #1: Type: text/plain, Size: 7257 bytes --]

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

> Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans@gmail.com> het volgende geschreven:
> 
> "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
> 
> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
> 
> > Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > 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
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> <signature.asc>


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 8832 bytes --]

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


Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
> 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
>
>> Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans@gmail.com> het volgende geschreven:
>>
>> "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
>>
>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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
>>
>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>>>
>>> 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
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> <signature.asc>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 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


[-- Attachment #2: Type: text/html, Size: 11384 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[nullius]

[-- Attachment #1: Type: text/plain, Size: 5699 bytes --]

On 2018-01-05 at 16:04:10 +0000, Sjors Provoost <sjors@sprovoost.nl> 
wrote:
>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]
>For my above point and some related ideas, see: 
>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.

-- 
nullius@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 11415 bytes --]

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


Le 05/01/2018 à 19:16, Alan Evans a écrit :
> 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 <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     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
>
>
>     Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>>     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
>>
>>>     Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans@gmail.com> <mailto:thealanevans@gmail.com> het volgende geschreven:
>>>
>>>     "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
>>>
>>>     On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>     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
>>>     <https://github.com/satoshilabs/slips/issues/103>
>>>
>>>     Sjors
>>>
>>>>     Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>>>>
>>>>     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
>>>>     bitcoin-dev@lists.linuxfoundation.org
>>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>     _______________________________________________
>>>     bitcoin-dev mailing list
>>>     bitcoin-dev@lists.linuxfoundation.org
>>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>
>>>
>>>     <signature.asc>
>>
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     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


[-- Attachment #2: Type: text/html, Size: 16309 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 23718 bytes --]

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)

Le 06/01/2018 à 16:00, Alan Evans a écrit :
> You're mistaken. BIP32 does not require a particular length. It
> recommends:
>
>   * Generate a seed byte sequence S of a chosen length (between 128
>     and 512 bits; 256 bits is advised) from a (P)RNG
>
> But BIP39 produces a 64 byte seed:
>
> 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 <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     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
>
>
>     Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
>     > 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
>     >
>     >
>     > Le 05/01/2018 à 21:38, Sjors Provoost a écrit :
>     >> 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
>     <thealanevans@gmail.com <mailto:thealanevans@gmail.com>> het
>     volgende geschreven:
>     >>>
>     >>> 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
>     >>>
>     >>> vs:
>     >>>
>     >>>
>     f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
>     >>>
>     >>> But they lead to the same addresses.
>     >>>
>     >>> Need I say more?
>     >>>
>     >>>
>     >>> On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>     >>> 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
>     >>>
>     >>> Le 05/01/2018 à 19:16, Alan Evans a écrit :
>     >>>> 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
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>     >>>> 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
>     >>>>
>     >>>> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>     >>>>> 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
>     >>>>>
>     >>>>>
>     >>>>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans
>     <thealanevans@gmail.com <mailto:thealanevans@gmail.com>>
>     >>>>>>  het volgende geschreven:
>     >>>>>>
>     >>>>>> "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
>     >>>>>>
>     >>>>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev
>     >>>>>> <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>     >>>>>>  wrote:
>     >>>>>> 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
>     <https://github.com/satoshilabs/slips/issues/103>
>     >>>>>>
>     >>>>>>
>     >>>>>> Sjors
>     >>>>>>
>     >>>>>>
>     >>>>>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>     >>>>>>>  het volgende geschreven:
>     >>>>>>>
>     >>>>>>> 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
>     <http://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
>     >>>>>>>
>     >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>>>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>     >>>>>> ______________________________
>     >>>>>> _________________
>     >>>>>> bitcoin-dev mailing list
>     >>>>>>
>     >>>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>> <signature.asc>
>     >>>>>>
>     >>>>> ______________________________
>     >>>>> _________________
>     >>>>> bitcoin-dev mailing list
>     >>>>>
>     >>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>
>     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
>     <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
>     <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
>     node-Tor <https://github.com/Ayms/torrent-live%0Anode-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


[-- Attachment #2: Type: text/html, Size: 41335 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 23969 bytes --]

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

Le 06/01/2018 à 19:28, Alan Evans a écrit :
> > 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
> repeat it says:
>
> 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.
>
>
>
> On Sat, Jan 6, 2018 at 1:40 PM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     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)
>
>
>     Le 06/01/2018 à 16:00, Alan Evans a écrit :
>>     You're mistaken. BIP32 does not require a particular length. It
>>     recommends:
>>
>>       * Generate a seed byte sequence S of a chosen length (between
>>         128 and 512 bits; 256 bits is advised) from a (P)RNG
>>
>>     But BIP39 produces a 64 byte seed:
>>
>>     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
>>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>>
>>         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
>>
>>
>>         Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
>>         > 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
>>         >
>>         >
>>         > Le 05/01/2018 à 21:38, Sjors Provoost a écrit :
>>         >> 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
>>         <thealanevans@gmail.com <mailto:thealanevans@gmail.com>> het
>>         volgende geschreven:
>>         >>>
>>         >>> 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
>>         >>>
>>         >>> vs:
>>         >>>
>>         >>>
>>         f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
>>         >>>
>>         >>> But they lead to the same addresses.
>>         >>>
>>         >>> Need I say more?
>>         >>>
>>         >>>
>>         >>> On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
>>         <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>>         >>> 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
>>         >>>
>>         >>> Le 05/01/2018 à 19:16, Alan Evans a écrit :
>>         >>>> 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
>>         <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>>         >>>> 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
>>         >>>>
>>         >>>> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a
>>         écrit :
>>         >>>>> 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
>>         >>>>>
>>         >>>>>
>>         >>>>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans
>>         <thealanevans@gmail.com <mailto:thealanevans@gmail.com>>
>>         >>>>>>  het volgende geschreven:
>>         >>>>>>
>>         >>>>>> "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
>>         >>>>>>
>>         >>>>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via
>>         bitcoin-dev
>>         >>>>>> <bitcoin-dev@lists.linuxfoundation.org
>>         <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>>         >>>>>>  wrote:
>>         >>>>>> 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
>>         <https://github.com/satoshilabs/slips/issues/103>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>> Sjors
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>> Op 5 jan. 2018, om 14:58 heeft nullius via
>>         bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>>         <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>>         >>>>>>>  het volgende geschreven:
>>         >>>>>>>
>>         >>>>>>> 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
>>         <http://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 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


[-- Attachment #2: Type: text/html, Size: 43706 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Pavol Rusnak]

[-- Attachment #1.1: Type: text/plain, Size: 957 bytes --]

On 05/01/18 14:58, nullius via bitcoin-dev wrote:
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[木ノ下じょな]

[-- Attachment #1: Type: text/plain, Size: 5321 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org>:

> On 05/01/18 14:58, nullius via bitcoin-dev wrote:
> > 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
> bitcoin-dev@lists.linuxfoundation.org
> 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-----

[-- Attachment #2: Type: text/html, Size: 6999 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[nullius]

[-- Attachment #1: Type: text/plain, Size: 4946 bytes --]

On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com> 
wrote:
>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!)

-- 
nullius@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 5714 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
>
>> 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!)
>
>
> --
> nullius@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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6715 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia]

[-- Attachment #1: Type: text/plain, Size: 6293 bytes --]

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
>>
>>> 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!)
>>
>>
>> --
>> nullius@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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!

[-- Attachment #2: Type: text/html, Size: 8151 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 6606 bytes --]

Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu@gmail.com>
wrote:

>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com> wrote:
>>>
>>>> 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!)
>>>
>>>
>>> --
>>> nullius@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
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Matías Alejo Garcia
> @ematiu
> Roads? Where we're going, we don't need roads!
>

[-- Attachment #2: Type: text/html, Size: 8841 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Matias Alejo Garcia]

[-- Attachment #1: Type: text/plain, Size: 7224 bytes --]

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

On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsanders87@gmail.com> wrote:

> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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 <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com>
>>>> wrote:
>>>>
>>>>> 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!)
>>>>
>>>>
>>>> --
>>>> nullius@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
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> 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!

[-- Attachment #2: Type: text/html, Size: 10012 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[AJ West]

[-- Attachment #1: Type: text/plain, Size: 9004 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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.
>
> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsanders87@gmail.com>
> wrote:
>
>> Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> 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 <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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!)
>>>>>
>>>>>
>>>>> --
>>>>> nullius@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
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 12746 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 9923 bytes --]

>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!

On Mon, Jan 8, 2018 at 10:26 AM, AJ West <ajwest@gmail.com> wrote:

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > 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.
>>
>> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsanders87@gmail.com>
>> wrote:
>>
>>> Let me re-phrase: Is it a known thing for users to actually use it?
>>>
>>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> 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 <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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!)
>>>>>>
>>>>>>
>>>>>> --
>>>>>> nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00
>>>>>> 591B2F307E0C
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> 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
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 14369 bytes --]

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 10726 bytes --]

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

Le 08/01/2018 à 15:54, Greg Sanders via bitcoin-dev a écrit :
> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu@gmail.com
> <mailto:ematiu@gmail.com>> wrote:
>
>
>
>     On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>         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
>         <bitcoin-dev@lists.linuxfoundation.org
>         <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>             On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな
>             <kinoshitajona@gmail.com <mailto:kinoshitajona@gmail.com>>
>             wrote:
>
>                 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!)
>
>
>             -- 
>             nullius@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
>
>             _______________________________________________
>             bitcoin-dev mailing list
>             bitcoin-dev@lists.linuxfoundation.org
>             <mailto:bitcoin-dev@lists.linuxfoundation.org>
>             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>             <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>         _______________________________________________
>         bitcoin-dev mailing list
>         bitcoin-dev@lists.linuxfoundation.org
>         <mailto:bitcoin-dev@lists.linuxfoundation.org>
>         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
> bitcoin-dev@lists.linuxfoundation.org
> 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


[-- Attachment #2: Type: text/html, Size: 22398 bytes --]