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

Iâm not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.

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

I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.

This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).

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

Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.

A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.

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

Sjors

I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"æ±è¯", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"æŒ¢èª", "zh-TW",ascii_space ),
LANG(french, u8"FranÃ§ais", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"æ¥æ¬èª", "ja", u8"\u3000" ),
LANG(korean, u8"íêµìŽ", "ko", ascii_space ),
LANG(spanish, u8"EspaÃ±ol", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, âzh-CNâ and âzh-TWâ, are imprecise at bestâinsofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
Should this proposal be âconcept ACKedâ by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Sjors Provoost via bitcoin-dev

2018-01-05 17:13:23 UTC

I donât know about Electrum but many wallets validate the English words, which helps in catching typos.

Hardware wallets without a full keyboard, like the Ledger Nano S, wonât even let you freely type characters; you have to select words from a list.

So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, youâll have fewer wallets to choose from.

I think itâs better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.

Sjors

"Very few wallets support anything other than English"
By support do you mean allow recovery, validation or generation or all three? For if you can freely type a phrase in (such as Electrum), or even word by word, then the likely-hood is it is supported if they remembered to normalize.
Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.
But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.
Alan
Iâm not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.
However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.
This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).
â¢ all words are 4-8 characters
â¢ all 4-character prefixes are unique (very useful for hardware wallets)
â¢ no two words have edit distance < 2
Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.
A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.
For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
Sjors

I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"æ±è¯", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"æŒ¢èª", "zh-TW",ascii_space ),
LANG(french, u8"FranÃ§ais", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"æ¥æ¬èª", "ja", u8"\u3000" ),
LANG(korean, u8"íêµìŽ", "ko", ascii_space ),
LANG(spanish, u8"EspaÃ±ol", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, âzh-CNâ and âzh-TWâ, are imprecise at bestâinsofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
Should this proposal be âconcept ACKedâ by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<signature.asc>

Aymeric Vitte via bitcoin-dev

2018-01-05 18:08:29 UTC

See: https://github.com/Ayms/bitcoin-transactions/issues/3

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

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

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

Multisig wallets (like Electrum) have created a big mess too, on purpose
or no, I don't know, but multisig is for different parties involved, not
just one

Post by Sjors Provoost via bitcoin-dev
I donât know about Electrum but many wallets validate the English words, which helps in catching typos.
Hardware wallets without a full keyboard, like the Ledger Nano S, wonât even let you freely type characters; you have to select words from a list.
So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, youâll have fewer wallets to choose from.
I think itâs better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.
Sjors

I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"æ±è¯", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"æŒ¢èª", "zh-TW",ascii_space ),
LANG(french, u8"FranÃ§ais", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"æ¥æ¬èª", "ja", u8"\u3000" ),
LANG(korean, u8"íêµìŽ", "ko", ascii_space ),
LANG(spanish, u8"EspaÃ±ol", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, âzh-CNâ and âzh-TWâ, are imprecise at bestâinsofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
Should this proposal be âconcept ACKedâ by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<signature.asc>

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

--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Aymeric Vitte via bitcoin-dev

2018-01-05 19:56:19 UTC

No that's not, some parts of the answer might be but this related, this
just shows how people use wrongly BIP39 and subsequent BIPs (and
globally other things), misleading them, while the advantage of using it
is quite dubious compared to backing up a seed, unless you can convince
me of the contrary

Sjors, well in Electrum, validation is optional, but English only. As
for the Ledger-S, that sounds like a Ledger problem.
Aymeric, that is way off topic, did you reply to wrong email?
See: https://github.com/Ayms/bitcoin-transactions/issues/3
<https://github.com/Ayms/bitcoin-transactions/issues/3>
OK, maybe it's my fault, I did not foresee this case, and now it's
working for p2sh (non segwit)
From my standpoint this just means that BIP39/44 stuff should be
eradicated (not BIP141 but see what happened...), this is of no
use, confusing people, doing dangerous things to recover
Really is it easier to save x words instead of a seed? Knowing
that people are creating several wallets not understanding that
this is not the purpose of BIP32?
Multisig wallets (like Electrum) have created a big mess too, on
purpose or no, I don't know, but multisig is for different parties
involved, not just one

I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
<https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"æ±è¯", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"æŒ¢èª", "zh-TW",ascii_space ),
LANG(french, u8"FranÃ§ais", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"æ¥æ¬èª", "ja", u8"\u3000" ),
LANG(korean, u8"íêµìŽ", "ko", ascii_space ),
LANG(spanish, u8"EspaÃ±ol", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, âzh-CNâ and âzh-TWâ, are imprecise at bestâinsofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
Should this proposal be âconcept ACKedâ by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
<signature.asc>

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

Aymeric Vitte via bitcoin-dev

2018-01-06 17:40:40 UTC

Unfortunately, even "yourself" seems not to know what he is talking
about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and messy
is quite dubious

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

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

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

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

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

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

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

Re-ccing the list because again at a certain point of time the theory
should look at the reality and adapt accordingly, part of the example I
gave is off topic for this thread but globally (which could become
another thread) the message is: the bitcoin community should stop making
things complicate for people, releasing BIPs of no use just ends up with
complicating things more than it helps, people deserve to understand
what they are doing, manage their keys by their own and stop syncing
useless full nodes for every coin to sync their wallets, that's why I
made the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't do
anything about this (btw the primary intent of the tool was for myself
and you are right for once, I did not know that people could do so big
mistakes, that's not their fault, I see it now, my mistake for
underestimating this)

You're mistaken. BIP32 does not require a particularÂ length. It
* Generate a seed byte sequence S of a chosen length (between 128
and 512 bits; 256 bits is advised) from a (P)RNG
The length of the derived key is 512 bits (= 64 bytes).
If you don't believe me, why don't you just try it? That seed will
derive the same keys as that mnemonic, it's a real example.
---------
About printing, there is a huge security risk involved in printing
anything. Networks, printers may have memory. People will print to PDF
when they don't have a printer on hand. Mobile users often can't print.
I wrote mine down, by hand, generated from an offline computer booted
with aÂ readonlyÂ OS.Â
Feel free to produce a recommendation to replace BIP39/32/44 if you
like, but it's not broken just because someone had trouble using your
tool/following your instructions. And no offence but I'd be wary using
a tool from someone who doesn't read the BIPs closely yet is so
confident about how other people are wrong.
And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
bytes as your wrote below, which probably corresponds to xprv,
which is
another misleading element of BIP39

The fact is indeed that "we should really find a way to overhaul

this

whole BIP 39 / 43/ 44 etc ad hoc mess"
Because the git example I provided is about someone that knows (to a
certain extent) what he is doing, then made a mistake for the
destination address, which is not related to this discussion
This just shows how complicate it can become even for people knowing
this to retrieve their wallet and how wallets made it "the easy

way" (ie

bip39, 44, multisig...)
If people prefer to store mnemonics, why not, but "writing down"

in both

messages above is not accurate, you would better print it and

cut it in

n pieces if you like, then the point of using mnemonics that you

can't

remember more than an hex string still remains useless from my

standpoint

Beside the theory we should look now if BIP39 & all brought more

good

than the contrary in practice, I think that the later wins

Hi Alan,
The Github issue is arguably unrelated, which is why I put it

at the end and said âsome relatedâ.

However it does all tie together; we should really find a way

to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess, ideally in
a way that even Bitcoin Core would be willing to use it. When you
change the word list, itâs best to change everything else at the
same time. Otherwise youâd have too many different standards,
which is a pain for wallets to implement.

I share your view than a mnemonic is better than a bunch of hex

numbers. Itâs easier to memorize and easier to write down. Some
people donât like it when users write down phrases, but theyâre
much, much more likely to lose their coins than some burglar to
find the piece of paper. My issue is only with the way derivation
currently works.

Sjors

Op 5 jan. 2018, om 21:05 heeft Alan Evans
Taking it off the board. I can't read all of that issue.

BIP0039 mnemonic generates a seed. Everything past there to do
with addresses (BIP32/44/49/141 whatever) is the same as if you
started with the seed. So you can't blaim BIP0039 for that
person's misunderstanding, and the way different wallets use
different derivation paths.

If someone has a BIP0039 mnemonic and would rather back up the

seed, they can go ahead. But one tiny mistake in writing it down
and you may have a hell of a time finding out what's wrong as
every seed is valid. A mistake in writing down words is far harder
to make. You can also memorize a mnemonic (hence the name), the
average person cannot memorize a seed.

fork canal mad beyond spike pool expire fuel region impose

ceiling video
f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64

But they lead to the same addresses.
Need I say more?
On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
No that's not, some parts of the answer might be but this

related, this just shows how people use wrongly BIP39 and
subsequent BIPs (and globally other things), misleading them,
while the advantage of using it is quite dubious compared to
backing up a seed, unless you can convince me of the contrary

Sjors, well in Electrum, validation is optional, but English

only. As for the Ledger-S, that sounds like a Ledger problem.

Aymeric, that is way off topic, did you reply to wrong email?
On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
See: https://github.com/Ayms/bitcoin-transactions/issues/3

<https://github.com/Ayms/bitcoin-transactions/issues/3>

OK, maybe it's my fault, I did not foresee this case, and now

it's working for p2sh (non segwit)

From my standpoint this just means that BIP39/44 stuff should

be eradicated (not BIP141 but see what happened...), this is of no
use, confusing people, doing dangerous things to recover

Really is it easier to save x words instead of a seed?

Knowing that people are creating several wallets not understanding
that this is not the purpose of BIP32?

Multisig wallets (like Electrum) have created a big mess too,

on purpose or no, I don't know, but multisig is for different
parties involved, not just one

Post by Sjors Provoost via bitcoin-dev
I donât know about Electrum but many wallets validate the

English words, which helps in catching typos.

Post by Sjors Provoost via bitcoin-dev
Hardware wallets without a full keyboard, like the Ledger

Nano S, wonât even let you freely type characters; you have to
select words from a list.

Post by Sjors Provoost via bitcoin-dev
So although the standard technically allows what you say, if

you use anything other than 12, 16 or 24 English words, youâll
have fewer wallets to choose from.

Post by Sjors Provoost via bitcoin-dev
I think itâs better to come up with a new standard than

trying to patch BIP-39 at this point, which is why I brought it up.

Post by Sjors Provoost via bitcoin-dev
Sjors

Op 5 jan. 2018, om 17:27 heeft Alan Evans
"Very few wallets support anything other than English"
By support do you mean allow recovery, validation or

generation or all three? For if you can freely type a phrase in
(such as Electrum), or even word by word, then the likely-hood is
it is supported if they remembered to normalize.

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

Â Â Â Â Â â¢ 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.

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

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

______________________________
_________________
bitcoin-dev mailing list

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

<signature.asc>

______________________________
_________________
bitcoin-dev mailing list

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

--
https://github.com/Ayms/bitcoin-transactions

<https://github.com/Ayms/bitcoin-transactions>

https://github.com/Ayms/zcash-wallets

<https://github.com/Ayms/zcash-wallets>

https://github.com/Ayms/bitcoin-wallets

<https://github.com/Ayms/bitcoin-wallets>

http://peersm.com/getblocklist
http://peersm.com/findmyass
http://torrent-live.org
http://www.peersm.com
https://github.com/Ayms/torrent-live

<https://github.com/Ayms/torrent-live>

https://www.github.com/Ayms/node-Tor

<https://www.github.com/Ayms/node-Tor>

https://www.github.com/Ayms

--
https://github.com/Ayms/bitcoin-transactions

<https://github.com/Ayms/bitcoin-transactions>

https://github.com/Ayms/zcash-wallets

<https://github.com/Ayms/zcash-wallets>

https://github.com/Ayms/bitcoin-wallets

<https://github.com/Ayms/bitcoin-wallets>

http://peersm.com/getblocklist
http://peersm.com/findmyass
http://torrent-live.org
http://www.peersm.com
https://github.com/Ayms/torrent-live

<https://github.com/Ayms/torrent-live>

https://www.github.com/Ayms/node-Tor

<https://www.github.com/Ayms/node-Tor>

https://www.github.com/Ayms

--
https://github.com/Ayms/bitcoin-transactions
<https://github.com/Ayms/bitcoin-transactions>
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
GitHub : https://www.github.com/Ayms

Aymeric Vitte via bitcoin-dev

2018-01-06 19:46:43 UTC

Post by Aymeric Vitte via bitcoin-dev

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

Â Unfortunately, even "yourself" seems not to know what he is talking

about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and
messy is quite dubious
And yet you still fail to read the BIP, do you want a
link?Â https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki I
between 128 and 512 bits
So, that's between 16 and 64 bytes, the advisory of 256 is clearly a
minimum.

Â That's another thing I completely dislike with BIP39, it ends up

with xpriv, not the 32B seed
Please also read
BIP0039Â https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki,
it generates *a BIP32 seed only*, no xpriv,Â that's completelyÂ false,
then you use BIP0032 as normal with the seed. Because BIP0039 produces
a seed, your whole argument goes out of the window, you can write the
seed if that's what you want to do, and throw away the mnemonic.
Unfortunately, even "yourself" seems not to know what he is
talking about (so imagine for other people, 256 bits is advised
--> 32B), probably that's why you brought this discussion off the
list, then making recommendations to improve something that is
misleading and messy is quite dubious
And maybe you should take a look at what people you are talking to
are doing before arguing stuff that you apparently don't know very
well (ie "the length of the *derived *key", not the seed), cf
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets> and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)
<https://github.com/Ayms/zcash-wallets>
But as you can notice there is a missing feature, ie to derive the
wallets from xpriv, there is a comment in the repo why I don't
like some things "Surprisingly from ~32 bytes keys BIP32 ends up
with a 78 bytes format to describe them with all the necessary
information like indexes, parent to possibly allow to revert the tree"
That's another thing I completely dislike with BIP39, it ends up
with xpriv, not the 32B seed, there are many, many, many posts in
forums of people fighting to figure out their private keys derived
from bip39/44/etc
"No offence too" but please keep your advises for yourself, I
indeed don't read closely inept BIPs, and never said I did not
like BIP32, that's the contrary, I really like it
Before firing plenty of BIPs that do not fit together people maybe
should take a break and see what people are doing today (this is
quite amazing) and why they got stolen
And you seem to know very little about security, if you suspect
you home printer, then suspect you OS, your hw, etc, (you really
envision to generate a seed from a mobile device ???) writing 64
characters is not very difficult for a human being, even easier
than writing x words of y length
See this too
https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887
<https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887>,
the tutorial was corrected, but basic things are still missing, an
offline version is when you disconnect from the internet, not when
you use the "offline version"Â (assuming that the browser storage
or other stuff are not used...)
Re-ccing the list because again at a certain point of time the
theory should look at the reality and adapt accordingly, part of
the example I gave is off topic for this thread but globally
(which could become another thread) the message is: the bitcoin
community should stop making things complicate for people,
releasing BIPs of no use just ends up with complicating things
more than it helps, people deserve to understand what they are
doing, manage their keys by their own and stop syncing useless
full nodes for every coin to sync their wallets, that's why I made
the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't
do anything about this (btw the primary intent of the tool was for
myself and you are right for once, I did not know that people
could do so big mistakes, that's not their fault, I see it now, my
mistake for underestimating this)

You're mistaken. BIP32 does not require a particularÂ length. It
* Generate a seed byte sequence S of a chosen length (between
128 and 512 bits; 256 bits is advised) from a (P)RNG
The length of the derived key is 512 bits (= 64 bytes).
If you don't believe me, why don't you just try it? That seed
will derive the same keys as that mnemonic, it's a real example.
---------
About printing, there is a huge security risk involved in
printing anything. Networks, printers may have memory. People
will print to PDF when they don't have a printer on hand. Mobile
users often can't print.
I wrote mine down, by hand, generated from an offline computer
booted with aÂ readonlyÂ OS.Â
Feel free to produce a recommendation to replace BIP39/32/44 if
you like, but it's not broken just because someone had trouble
using your tool/following your instructions. And no offence but
I'd be wary using a tool from someone who doesn't read the BIPs
closely yet is so confident about how other people are wrong.
On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte
And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
bytes as your wrote below, which probably corresponds to
xprv, which is
another misleading element of BIP39

The fact is indeed that "we should really find a way to

overhaul this

whole BIP 39 / 43/ 44 etc ad hoc mess"
Because the git example I provided is about someone that

knows (to a

certain extent) what he is doing, then made a mistake for the
destination address, which is not related to this discussion
This just shows how complicate it can become even for

people knowing

this to retrieve their wallet and how wallets made it "the

easy way" (ie

bip39, 44, multisig...)
If people prefer to store mnemonics, why not, but "writing

down" in both

messages above is not accurate, you would better print it

and cut it in

n pieces if you like, then the point of using mnemonics

that you can't

remember more than an hex string still remains useless from

my standpoint

Beside the theory we should look now if BIP39 & all brought

more good

than the contrary in practice, I think that the later wins

Hi Alan,
The Github issue is arguably unrelated, which is why I put

it at the end and said âsome relatedâ.

However it does all tie together; we should really find a

way to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess,
ideally in a way that even Bitcoin Core would be willing to
use it. When you change the word list, itâs best to change
everything else at the same time. Otherwise youâd have too
many different standards, which is a pain for wallets to
implement.

I share your view than a mnemonic is better than a bunch

of hex numbers. Itâs easier to memorize and easier to write
down. Some people donât like it when users write down
phrases, but theyâre much, much more likely to lose their
coins than some burglar to find the piece of paper. My issue
is only with the way derivation currently works.

Sjors

Op 5 jan. 2018, om 21:05 heeft Alan Evans
Taking it off the board. I can't read all of that issue.

BIP0039 mnemonic generates a seed. Everything past there to
do with addresses (BIP32/44/49/141 whatever) is the same as
if you started with the seed. So you can't blaim BIP0039 for
that person's misunderstanding, and the way different wallets
use different derivation paths.

If someone has a BIP0039 mnemonic and would rather back

up the seed, they can go ahead. But one tiny mistake in
writing it down and you may have a hell of a time finding out
what's wrong as every seed is valid. A mistake in writing
down words is far harder to make. You can also memorize a
mnemonic (hence the name), the average person cannot memorize
a seed.

fork canal mad beyond spike pool expire fuel region

impose ceiling video
f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64

But they lead to the same addresses.
Need I say more?
On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
No that's not, some parts of the answer might be but this

Sjors, well in Electrum, validation is optional, but

English only. As for the Ledger-S, that sounds like a Ledger
problem.

Aymeric, that is way off topic, did you reply to wrong

email?

On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte

https://github.com/Ayms/bitcoin-transactions/issues/3
<https://github.com/Ayms/bitcoin-transactions/issues/3>

OK, maybe it's my fault, I did not foresee this case,

and now it's working for p2sh (non segwit)

From my standpoint this just means that BIP39/44 stuff

should be eradicated (not BIP141 but see what happened...),
this is of no use, confusing people, doing dangerous things
to recover

Really is it easier to save x words instead of a seed?

Knowing that people are creating several wallets not
understanding that this is not the purpose of BIP32?

Multisig wallets (like Electrum) have created a big mess

too, on purpose or no, I don't know, but multisig is for
different parties involved, not just one

Le 05/01/2018 Ã 18:13, Sjors Provoost via bitcoin-dev a

Post by Sjors Provoost via bitcoin-dev
I donât know about Electrum but many wallets validate

the English words, which helps in catching typos.

Post by Sjors Provoost via bitcoin-dev
Hardware wallets without a full keyboard, like the

Ledger Nano S, wonât even let you freely type characters; you
have to select words from a list.

Post by Sjors Provoost via bitcoin-dev
So although the standard technically allows what you

say, if you use anything other than 12, 16 or 24 English
words, youâll have fewer wallets to choose from.

Post by Sjors Provoost via bitcoin-dev
I think itâs better to come up with a new standard than

trying to patch BIP-39 at this point, which is why I brought it up.

Post by Sjors Provoost via bitcoin-dev
Sjors

Op 5 jan. 2018, om 17:27 heeft Alan Evans
"Very few wallets support anything other than English"
By support do you mean allow recovery, validation or

generation or all three? For if you can freely type a phrase
in (such as Electrum), or even word by word, then the
likely-hood is it is supported if they remembered to normalize.

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

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

Â Â Â Â Â â¢ 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.

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

______________________________

nullius via bitcoin-dev

2018-01-05 18:08:50 UTC

Post by Sjors Provoost via bitcoin-dev
Iâm not a fan of language specific word lists within the current BIP-39
standard. Very few wallets support anything other than English, which
can lead to vendor lock-in and long term loss of funds if a rare
non-English wallet disappears.
However, because people can memorize things better in their native
tongue, supporting multiple languages seems quite useful.
I would prefer a new standard [...] A replacement for BIP-39 [...]
[snip]
https://github.com/satoshilabs/slips/issues/103

You present some interesting ideas; and I will be much interested in the
Github issue you referencedâthanks for that. However, this discussion
is *far* beyond the scope of my simple proposal and request to add
standardized native language and short-ASCII identifier strings to the
BIP repository. I suggest that readers solely interested in the
existing BIP 39 standard and its direct application to Bitcoin should
stop reading right here.

----

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

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

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

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

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

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

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

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

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

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

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

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

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

Further discussion is invited by private mail, in an appropriate public
venue, or otherwise not on a bitcoin-dev thread which makes a simple
request and proposal as to the existing BIP 39 standardâthanks.

--
***@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius

Pavol Rusnak via bitcoin-dev

2018-01-07 15:16:47 UTC

Post by nullius via bitcoin-dev
I propose and request as an enhancement that the BIP 39 wordlist set
should specify canonical native language strings to identify each
wordlist, as well as short ASCII language codes. At present, the
languages are identified only by their names in English.

I am advising not to use any other language than English for BIP39. I
got persuaded to allow more languages when writing BIP39 spec, but I
learned that it was something I should've been more persistently against.

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

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

--
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

木ノ下じょな via bitcoin-dev

2018-01-08 07:35:52 UTC

Post by Pavol Rusnak via bitcoin-dev

This is very sad.

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

I have seen a 60 year old Japanese man writing down his phrase (because he
kept on failing recovery), and watched him write down "aneter" for
"amateur"...
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 <

I am advising not to use any other language than English for BIP39. I
got persuaded to allow more languages when writing BIP39 spec, but I
learned that it was something I should've been more persistently against.
I am currently drafting a new standard[1] which will allow also Shamir
Secret Scheme Splitting and there we disallow usage of a custom wordlist
in order to eradicate this mess. Will try to push this as BIP too once
we get it to the point we are OK with the contents.
https://github.com/satoshilabs/slips/blob/master/slip-0039.md
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: http://openpgpjs.org

xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
Spe3vsHZr6CqFg==
=/vUJ
-----END PGP PUBLIC KEY BLOCK-----

nullius via bitcoin-dev

2018-01-08 11:13:28 UTC

Post by æ¨ãä¸ãããª via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase (because
he kept on failing recovery), and watched him write down "aneter" for
"amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.

Well said. Thank you for telling of these experiences. Now please,
letâs put the shoe on the other foot.

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

ãããããããããããããããããŠããããããšã
ãšãããã¯ãããããããŸãã»ããããã¡ãã£ãµãããã€

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

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

ã«ããããã²ãããã«ããããã²ãããããããããã®ããããããã¯ããããã²ãã
ãšãããããããããããªããããªããªãã«ããããããããããããããããã¿ãã
ãžããããã²ããããããã²ããµããããããããããããããããŸã

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

----

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

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

----

I began this thread with a quite simple request: Is âæ¥æ¬èªâ an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?

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

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

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

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

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

(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should
go without saying, easyseed output the Japanese perfectly!)

Greg Sanders via bitcoin-dev

2018-01-08 14:34:39 UTC

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 <

Well said. Thank you for telling of these experiences. Now please, letâs
put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
ããã ããã ããã ããã ãŠããã ããšã
ãšãã ã¯ãã ããããŸ ã»ãã ãã¡ãã£ãµ ããã€
(Approximate translation: âWhatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?â)
No, wait: That is only a 12-word mnemonic. We are probably talking about
a Trezor; so now, hey you there, stake the backup of your lifeâs savings on
ã«ãã ãã²ãã ã«ããã ã²ãã ãããã ãã®ã ããã ã¯ããã ã²ãã
ãšãã ããããã ããªã ããªããª ã«ãããããã ããã ãããã ã¿ãã
ãžãã ãã²ãã ãããã² ãµãã ããã ããããã ãããŸã
Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friendsâif BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their âmnemonicsâ.
In such cases, the phrases cannot be called âmnemonicsâ at all. A
âmnemonicâ implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote âaneterâ for âamateurâ, was not
dealing with a *mnemonic*: He was using the worldâs most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is âæ¥æ¬èªâ an appropriate
string for identifying the Japanese language to Japanese users? And what
of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the greatest
guard against vendor lock-in and stale software: Independent
implementations. â I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism of
multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of âEnglish only!â
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called âBIP 39â which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing. I
have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Greg Sanders via bitcoin-dev

2018-01-08 14:54:38 UTC

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

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?

Copay (and all its clones) use it.

Post by Greg Sanders via bitcoin-dev
If a feature of the standard has not been(widely?) used in years, and
isn't supported in any major wallet(?), it seems indicative it was a
mistake to add it in the first place, since it's a footgun in the making
for some poor sap who can't even read English letters when almost all
documentation is written in English.
On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <

Well said. Thank you for telling of these experiences. Now please,
letâs put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
ããã ããã ããã ããã ãŠããã ããšã
ãšãã ã¯ãã ããããŸ ã»ãã ãã¡ãã£ãµ ããã€
(Approximate translation: âWhatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?â)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your lifeâs
ã«ãã ãã²ãã ã«ããã ã²ãã ãããã ãã®ã ããã ã¯ããã ã²ãã
ãšãã ããããã ããªã ããªããª ã«ãããããã ããã ãããã ã¿ãã
ãžãã ãã²ãã ãããã² ãµãã ããã ããããã ãããŸã
Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friendsâif BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their âmnemonicsâ.
In such cases, the phrases cannot be called âmnemonicsâ at all. A
âmnemonicâ implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote âaneterâ for âamateurâ, was not
dealing with a *mnemonic*: He was using the worldâs most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is âæ¥æ¬èªâ an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. â I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of âEnglish only!â
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called âBIP 39â which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

Matias Alejo Garcia via bitcoin-dev

2018-01-08 15:23:53 UTC

Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?

yes. Based on language stats from the app stores, roughly 30% to 40% of
Copay users have their backup on a language
other than English, and we constantly get requests to support new languages
in BIP39.

Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?

Copay (and all its clones) use it.

Post by æ¨ãä¸ãããª via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier to
plan for" is not a good way to move forward as a currency.

Well said. Thank you for telling of these experiences. Now please,
letâs put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
ããã ããã ããã ããã ãŠããã ããšã
ãšãã ã¯ãã ããããŸ ã»ãã ãã¡ãã£ãµ ããã€
(Approximate translation: âWhatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?â)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your lifeâs
ã«ãã ãã²ãã ã«ããã ã²ãã ãããã ãã®ã ããã ã¯ããã ã²ãã
ãšãã ããããã ããªã ããªããª ã«ãããããã ããã ãããã ã¿ãã
ãžãã ãã²ãã ãããã² ãµãã ããã ããããã ãããŸã
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friendsâif BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their âmnemonicsâ.
In such cases, the phrases cannot be called âmnemonicsâ at all. A
âmnemonicâ implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote âaneterâ for âamateurâ, was not
dealing with a *mnemonic*: He was using the worldâs most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is âæ¥æ¬èªâ an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. â I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other languages,
and I am getting replies which raise a hue and cry of âEnglish only!â
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called âBIP 39â which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should go
without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

AJ West via bitcoin-dev

2018-01-08 15:26:38 UTC

Post by Matias Alejo Garcia via bitcoin-dev

Greg yes, there were already examples in this very thread of people
explaining how they use languages other than English. I'm shocked that so
many people are resisting the idea that just *maybe* there could be people
in other parts of the world who do not want to use or cannot use the strict
set of latin characters and words from the English language.

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

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

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

On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?

Copay (and all its clones) use it.

Post by æ¨ãä¸ãããª via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier
to plan for" is not a good way to move forward as a currency.

Well said. Thank you for telling of these experiences. Now please,
letâs put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
ããã ããã ããã ããã ãŠããã ããšã
ãšãã ã¯ãã ããããŸ ã»ãã ãã¡ãã£ãµ ããã€
(Approximate translation: âWhatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?â)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your lifeâs
ã«ãã ãã²ãã ã«ããã ã²ãã ãããã ãã®ã ããã ã¯ããã ã²ãã
ãšãã ããããã ããªã ããªããª ã«ãããããã ããã ãããã ã¿ãã
ãžãã ãã²ãã ãããã² ãµãã ããã ããããã ãããŸã
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friendsâif BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their âmnemonicsâ.
In such cases, the phrases cannot be called âmnemonicsâ at all. A
âmnemonicâ implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote âaneterâ for âamateurâ, was not
dealing with a *mnemonic*: He was using the worldâs most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is âæ¥æ¬èªâ an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. â I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into
criticism of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of âEnglish
only!â
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called âBIP 39â which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate
for use with that standard.
(P.S., I hope that my system did not mangle anything in the
foregoing. I have seen weird copypaste behaviour mess up decomposed
characters. I thought of this after I searched for and collected some
visually fascinating phrases; so I tried to normalize these to NFC... It
should go without saying, easyseed output the Japanese perfectly!)
--
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

--
MatÃas Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Greg Sanders via bitcoin-dev

2018-01-08 15:32:58 UTC

Post by Matias Alejo Garcia via bitcoin-dev

I'm shocked that so many people are resisting the idea that just *maybe* there

could be people in other parts of the world who do not want to use or
cannot use the strict set of latin characters and words from the English
language.

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

If I'm wrong, great, more people can use software strictly in their native
language in a safe manner!

Greg yes, there were already examples in this very thread of people
explaining how they use languages other than English. I'm shocked that so
many people are resisting the idea that just *maybe* there could be
people in other parts of the world who do not want to use or cannot use the
strict set of latin characters and words from the English language.
I agree with Sjors and maybe I'm simplifying too much, but can't we just
map an existing ISO/UTF language character standard to the seeds? Why is
there a word list at all? Choose a flexible encoding standard, create a
clever map to the bytes, make sure to include a checksum.
As an aside, I know there are some conventions which add space for error
correction but I personally don't love the idea of somebody inputting what
they think is the proper seed, only to have it auto-corrected and thus
reinforcing their erroneously saved/written seed backup.
Pavol, why do you say "I learned that it was something I should've been
more persistently against?" I still can't see any good arguments as to why
we should limit this to English other than "It's easier to support a single
language" which comes at the cost of "It's hard for me to backup my seed"
for those who don't speak English.
On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <

Post by Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?

Copay (and all its clones) use it.

Post by æ¨ãä¸ãããª via bitcoin-dev
This is very sad.
The number one problem in Japan with BIP39 seeds is with English words.
I have seen a 60 year old Japanese man writing down his phrase
(because he kept on failing recovery), and watched him write down "aneter"
for "amateur"...
[...]
If you understand English and can spell, you read a word, your brain
processes the word, and you can spell it on your own when writing down.
Not many Japanese people can do that, so they need to copy letter for
letter, taking a long time, and still messing up on occasion.
[...]
Defining "everyone should only use English, because ASCII is easier
to plan for" is not a good way to move forward as a currency.

Well said. Thank you for telling of these experiences. Now please,
letâs put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to
entrust *their own money* to their abilities to very, very carefully write
ããã ããã ããã ããã ãŠããã ããšã
ãšãã ã¯ãã ããããŸ ã»ãã ãã¡ãã£ãµ ããã€
(Approximate translation: âWhatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?â)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your lifeâs
ã«ãã ãã²ãã ã«ããã ã²ãã ãããã ãã®ã ããã ã¯ããã ã²ãã
ãšãã ããããã ããªã ããªããª ã«ãããããã ããã ãããã ã¿ãã
ãžãã ãã²ãã ãããã² ãµãã ããã ããããã ãããŸã
Ready to bet your money on *that* as a backup phrase in your own
hands? No? Then please, stop demanding that others risk *their* money on
the inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then think
of how much money would be lost by your non-Japanese-literate family and
friendsâif BIP 39 had only Japanese wordlists, and your folks needed to
wrestle with the above phrases as their âmnemonicsâ.
In such cases, the phrases cannot be called âmnemonicsâ at all. A
âmnemonicâ implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings. The
Japanese man in the quoted story, who wrote âaneterâ for âamateurâ, was not
dealing with a *mnemonic*: He was using the worldâs most inefficient means
of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is âæ¥æ¬èªâ an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. â I asked, because obviously, I myself do not speak all
these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into
criticism of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of âEnglish
only!â
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially restricted
to English. I am fortunate; for as of this moment, we have a standard
called âBIP 39â which has seven non-English wordlists, and four more
pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate
for use with that standard.
(P.S., I hope that my system did not mangle anything in the
foregoing. I have seen weird copypaste behaviour mess up decomposed
characters. I thought of this after I searched for and collected some
visually fascinating phrases; so I tried to normalize these to NFC... It
should go without saying, easyseed output the Japanese perfectly!)
--
591B2F307E0C
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
ââIf youâre not doing anything wrong, you have nothing to hide.â
No! Because I do nothing wrong, I have nothing to show.â â nullius
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

Aymeric Vitte via bitcoin-dev

2018-01-08 16:02:02 UTC