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

[Aymeric Vitte via bitcoin-dev]

That's the point indeed and the scope is wider than XYZIP-39, even if
what I mean is the very contrary of your point (really bitcoin is
reserved to an elite understanding english/ascii letters?)

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

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

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

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

"yet I would not advise users to use a wordlist that might not have
support across multiple wallet implementations, resulting in lock-in or
worse"--> this single sentence shows how the whole model is wrong and
how you think that you can lock people

Le 08/01/2018 à 15:54, Greg Sanders via bitcoin-dev a écrit :
> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia  > wrote:
>
>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
>  > wrote:
>
> Has anyone actually used the multilingual support in bip39?
>
>
>
> Copay (and all its clones) use it. 
>
>
>
>  
>
>
> If a feature of the standard has not been(widely?) used in
> years, and isn't supported in any major wallet(?), it seems
> indicative it was a mistake to add it in the first place,
> since it's a footgun in the making for some poor sap who can't
> even read English letters when almost all documentation is
> written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev
>  > wrote:
>
> On 2018-01-08 at 07:35:52 +, 木ノ下じょな
> >
> wrote:
>
> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is
> with English words.
>
> I have seen a 60 year old Japanese man writing down
> his phrase (because he kept on failing recovery), and
> watched him write down "aneter" for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a
> word, your brain processes the word, and you can spell
> it on your own when writing down.  Not many Japanese
> people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on
> occasion.
>
> [...]
>
> Defining "everyone should only use English, because
> ASCII is easier to plan for" is not a good way to move
> forward as a currency.
>
>
> Well said.  Thank you for telling of these experiences. 
> Now please, let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic
> standard to entrust *their own money* to their abilities
> to very, very carefully write this down—then later, type
> it back in:
>
> すさん　たんろ　りゆう　しもん　ていおん　しとう
> とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ
>
> (Approximate translation:  “Whatever would you do if
> Bitcoin had been invented by somebody named Satoshi
> Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are
> probably talking about a Trezor; so now, hey you there,
> stake the backup of your life’s savings on your ability to
> handwrite *this*:
>
> にあう　しひょう　にんすう　ひえる　かいこう　いのる　ねんし　はあさん　ひこく
> とうく　きもためし　そなた　こなこな　にさんかたんそ　ろんき　めいあん　みわく
> へこむ　すひょう　おやゆひ　ふせく　けさき　めいきょく　こんまけ
>
> Ready to bet your money on *that* as a backup phrase in
> your own 

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

[Greg Sanders 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!

On Mon, Jan 8, 2018 at 10:26 AM, AJ West  wrote:

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


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

> Has anyone actually used the multilingual support in bip39?
>


 Copay (and all its clones) use it.





>
> If a feature of the standard has not been(widely?) used in years, and
> isn't supported in any major wallet(?), it seems indicative it was a
> mistake to add it in the first place, since it's a footgun in the making
> for some poor sap who can't even read English letters when almost all
> documentation is written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
>> wrote:
>>
>>> This is very sad.
>>>
>>> The number one problem in Japan with BIP39 seeds is with English
>>> words.
>>>
>>> I have seen a 60 year old Japanese man writing down his phrase
>>> (because he kept on failing recovery), and watched him write down 
>>> "aneter"
>>> for "amateur"...
>>>
>>> [...]
>>>
>>> If you understand English and can spell, you read a word, your brain
>>> processes the word, and you can spell it on your own when writing down.
>>> Not many Japanese people can do that, so they need to copy letter for
>>> letter, taking a long time, and still messing up on occasion.
>>>
>>> [...]
>>>
>>> Defining "everyone should only use English, because ASCII is easier
>>> to plan for" is not a good way to move forward as a currency.
>>>
>>
>> Well said.  Thank you for telling of these experiences.  Now please,
>> let’s put the shoe on the other foot.
>>
>> I ask everybody who wants an English-only mnemonic standard to
>> entrust *their own money* to their abilities to very, very carefully 
>> write
>> this down—then later, type it back in:
>>
>> すさん たんろ りゆう しもん ていおん しとう
>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>
>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>> invented by somebody named Satoshi Nakamoto?”)
>>
>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>> about a Trezor; so now, hey you there, stake 

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

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

> > Let me re-phrase: Is it a known thing for users to actually use it?
>
> yes. Based on language stats from the app stores, roughly 30% to 40% of
> Copay users have their backup on a language
> other than English, and we constantly get requests to support new
> languages in BIP39.
>
> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders 
> wrote:
>
>> Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Has anyone actually used the multilingual support in bip39?

>>>
>>>
>>> Copay (and all its clones) use it.
>>>
>>>
>>>
>>>
>>>

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

 On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
> wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English
>> words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase
>> (because he kept on failing recovery), and watched him write down 
>> "aneter"
>> for "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier
>> to plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please,
> let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking
> about a Trezor; so now, hey you there, stake the backup of your life’s
> savings on your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own
> hands?  No?  Then please, stop demanding that others risk *their* money on
> the inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then 
> think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.

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

[Matias Alejo Garcia 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.

On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders  wrote:

> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia 
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Has anyone actually used the multilingual support in bip39?
>>>
>>
>>
>> Copay (and all its clones) use it.
>>
>>
>>
>>
>>
>>>
>>> If a feature of the standard has not been(widely?) used in years, and
>>> isn't supported in any major wallet(?), it seems indicative it was a
>>> mistake to add it in the first place, since it's a footgun in the making
>>> for some poor sap who can't even read English letters when almost all
>>> documentation is written in English.
>>>
>>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 On 2018-01-08 at 07:35:52 +, 木ノ下じょな 
 wrote:

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

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

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

 すさん たんろ りゆう しもん ていおん しとう
 とこや はやい おうさま ほくろ けちゃっふ たもつ

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

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

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

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

 

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

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

 

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

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

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

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

 Though I am fluent and literate in English, I am uninterested in ever
 implementing any standard of 

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

[Matias Alejo Garcia via bitcoin-dev]

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

> Has anyone actually used the multilingual support in bip39?
>


Copay (and all its clones) use it.





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

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

[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 9:52 AM, Matias Alejo Garcia 
wrote:

>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Has anyone actually used the multilingual support in bip39?
>>
>
>
> Copay (and all its clones) use it.
>
>
>
>
>
>>
>> If a feature of the standard has not been(widely?) used in years, and
>> isn't supported in any major wallet(?), it seems indicative it was a
>> mistake to add it in the first place, since it's a footgun in the making
>> for some poor sap who can't even read English letters when almost all
>> documentation is written in English.
>>
>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>>>
 This is very sad.

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

 I have seen a 60 year old Japanese man writing down his phrase (because
 he kept on failing recovery), and watched him write down "aneter" for
 "amateur"...

 [...]

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

 [...]

 Defining "everyone should only use English, because ASCII is easier to
 plan for" is not a good way to move forward as a currency.

>>>
>>> Well said.  Thank you for telling of these experiences.  Now please,
>>> let’s put the shoe on the other foot.
>>>
>>> I ask everybody who wants an English-only mnemonic standard to entrust
>>> *their own money* to their abilities to very, very carefully write this
>>> down—then later, type it back in:
>>>
>>> すさん たんろ りゆう しもん ていおん しとう
>>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>>
>>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>>> invented by somebody named Satoshi Nakamoto?”)
>>>
>>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>>> about a Trezor; so now, hey you there, stake the backup of your life’s
>>> savings on your ability to handwrite *this*:
>>>
>>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>>
>>> Ready to bet your money on *that* as a backup phrase in your own hands?
>>> No?  Then please, stop demanding that others risk *their* money on the
>>> inverse case.
>>>
>>> 
>>>
>>> If you cheat here by having studied Japanese, then remember that many
>>> Japanese people know English and other European languages, too.  Then think
>>> of how much money would be lost by your non-Japanese-literate family and
>>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>>> wrestle with the above phrases as their “mnemonics”.
>>>
>>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>>> system is much worse even than transcribing pseudorandom hex strings.  The
>>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>>> of making cryptic bitstrings *less* userfriendly.
>>>
>>> 
>>>
>>> I began this thread with a quite simple request:  Is “日本語” an
>>> appropriate string for identifying the Japanese language to Japanese
>>> users?  And what of the other strings I posted for other languages?
>>>
>>> I asked this as an implementer working on my own instance of the
>>> greatest guard against vendor lock-in and stale software:  Independent
>>> implementations.  —  I asked, because obviously, I myself do not speak all
>>> these different languages; and I want to implement them all.  *All.*
>>>
>>> Some replies have been interesting in their own right; but thus far,
>>> nobody has squarely addressed the substance of my question.
>>>
>>> Most worrisome is that much of the discussion has veered into criticism
>>> of multi-language support.  I opened with a question about other languages,
>>> and I am getting replies which raise a hue and cry of “English only!”
>>>
>>> Though I am fluent and literate in English, I am uninterested in ever
>>> implementing any standard of this nature which is artificially restricted
>>> to English.  I am fortunate; for as of this moment, we have a standard
>>> called “BIP 39” which has seven non-English wordlists, and four more
>>> pending in open pull requests (#432, #442, #493, #621).
>>>
>>> I request discussion of language identification strings appropriate for
>>> use with that standard.
>>>
>>> (P.S., I hope that my system did not mangle anything in the foregoing.
>>> I have seen weird copypaste 

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

[Greg Sanders via bitcoin-dev]

Has anyone actually used the multilingual support in bip39?

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

On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase (because
>> he kept on failing recovery), and watched him write down "aneter" for
>> "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier to
>> plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please, let’s
> put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking about
> a Trezor; so now, hey you there, stake the backup of your life’s savings on
> your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own hands?
> No?  Then please, stop demanding that others risk *their* money on the
> inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.
>
> In such cases, the phrases cannot be called “mnemonics” at all.  A
> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
> system is much worse even than transcribing pseudorandom hex strings.  The
> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
> dealing with a *mnemonic*:  He was using the world’s most inefficient means
> of making cryptic bitstrings *less* userfriendly.
>
> 
>
> I began this thread with a quite simple request:  Is “日本語” an appropriate
> string for identifying the Japanese language to Japanese users?  And what
> of the other strings I posted for other languages?
>
> I asked this as an implementer working on my own instance of the greatest
> guard against vendor lock-in and stale software:  Independent
> implementations.  —  I asked, because obviously, I myself do not speak all
> these different languages; and I want to implement them all.  *All.*
>
> Some replies have been interesting in their own right; but thus far,
> nobody has squarely addressed the substance of my question.
>
> Most worrisome is that much of the discussion has veered into criticism of
> multi-language support.  I opened with a question about other languages,
> and I am getting replies which raise a hue and cry of “English only!”
>
> Though I am fluent and literate in English, I am uninterested in ever
> implementing any standard of this nature which is artificially restricted
> to English.  I am fortunate; for as of this moment, we have a standard
> called “BIP 39” which has seven non-English wordlists, and four more
> pending in open pull requests (#432, #442, #493, #621).
>
> I request discussion of language identification strings appropriate for
> use with that standard.
>
> (P.S., I hope that my system did not mangle anything in the foregoing.  I
> have seen weird copypaste behaviour mess up decomposed characters.  I
> thought of this after I searched for and collected some visually
> fascinating phrases; so I tried to normalize these to NFC...  It should go
> without saying, easyseed output the Japanese perfectly!)
>
>
> --
> null...@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.’

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

[nullius via bitcoin-dev]

On 2018-01-08 at 07:35:52 +, 木ノ下じょな  
wrote:

This is very sad.

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

I have seen a 60 year old Japanese man writing down his phrase (because 
he kept on failing recovery), and watched him write down "aneter" for 
"amateur"...


[...]

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


[...]

Defining "everyone should only use English, because ASCII is easier to 
plan for" is not a good way to move forward as a currency.


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


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


すさん　たんろ　りゆう　しもん　ていおん　しとう
とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ

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


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


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

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




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


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




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


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


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


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


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


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


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


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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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

Le 06/01/2018 à 19:28, Alan Evans a écrit :
> > Unfortunately, even "yourself" seems not to know what he is talking
> about (so imagine for other people, 256 bits is advised --> 32B),
> probably that's why you brought this discussion off the list, then
> making recommendations to improve something that is misleading and
> messy is quite dubious
>
> And yet you still fail to read the BIP, do you want a
> link? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki I
> repeat it says:
>
> between 128 and 512 bits
>
> So, that's between 16 and 64 bytes, the advisory of 256 is clearly a
> minimum.
>
> > That's another thing I completely dislike with BIP39, it ends up
> with xpriv, not the 32B seed
>
> Please also read
> BIP0039 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki,
> it generates *a BIP32 seed only*, no xpriv, that's completely false,
> then you use BIP0032 as normal with the seed. Because BIP0039 produces
> a seed, your whole argument goes out of the window, you can write the
> seed if that's what you want to do, and throw away the mnemonic.
>
>
>
> On Sat, Jan 6, 2018 at 1:40 PM, Aymeric Vitte  > wrote:
>
> Unfortunately, even "yourself" seems not to know what he is
> talking about (so imagine for other people, 256 bits is advised
> --> 32B), probably that's why you brought this discussion off the
> list, then making recommendations to improve something that is
> misleading and messy is quite dubious
>
> And maybe you should take a look at what people you are talking to
> are doing before arguing stuff that you apparently don't know very
> well (ie "the length of the *derived *key", not the seed), cf
> https://github.com/Ayms/bitcoin-wallets
>  and even
> https://github.com/Ayms/zcash-wallets (not official but
> https://github.com/zcash/zips/issues/95)
> 
>
> 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: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

[Aymeric Vitte via bitcoin-dev]

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

And 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
 and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)


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

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

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

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

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

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

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

Le 06/01/2018 à 16:00, Alan Evans a écrit :
> You're mistaken. BIP32 does not require a particular length. It
> recommends:
>
>   * Generate a seed byte sequence S of a chosen length (between 128
> and 512 bits; 256 bits is advised) from a (P)RNG
>
> But BIP39 produces a 64 byte seed:
>
> The length of the derived key is 512 bits (= 64 bytes).
>
> If you don't believe me, why don't you just try it? That seed will
> derive the same keys as that mnemonic, it's a real example.
>
> -
>
> About printing, there is a huge security risk involved in printing
> anything. Networks, printers may have memory. People will print to PDF
> when they don't have a printer on hand. Mobile users often can't print.
>
> I wrote mine down, by hand, generated from an offline computer booted
> with a readonly OS. 
>
> Feel free to produce a recommendation to replace BIP39/32/44 if you
> like, but it's not broken just because someone had trouble using your
> tool/following your instructions. And no offence but I'd be wary using
> a tool from someone who doesn't read the BIPs closely yet is so
> confident about how other people are wrong.
>
>
> On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte  > wrote:
>
> And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
> bytes as your wrote below, which probably corresponds to xprv,
> which is
> another misleading element of BIP39
>
>
> Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
> > The fact is indeed that "we should really find a way to overhaul
> this
> > whole BIP 39 / 43/ 44 etc ad hoc mess"
> >
> > Because the git example I provided is about someone that knows (to a
> > certain extent) what he is doing, then 

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

[Pavol Rusnak via bitcoin-dev]

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

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

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

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

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Aymeric Vitte via bitcoin-dev]

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


Le 05/01/2018 à 19:16, Alan Evans a écrit :
> Sjors, well in Electrum, validation is optional, but English only. As
> for the Ledger-S, that sounds like a Ledger problem.
>
> Aymeric, that is way off topic, did you reply to wrong email?
>
> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte  > wrote:
>
> See: https://github.com/Ayms/bitcoin-transactions/issues/3
> 
>
> OK, maybe it's my fault, I did not foresee this case, and now it's
> working for p2sh (non segwit)
>
> From my standpoint this just means that BIP39/44 stuff should be
> eradicated (not BIP141 but see what happened...), this is of no
> use, confusing people, doing dangerous things to recover
>
> Really is it easier to save x words instead of a seed? Knowing
> that people are creating several wallets not understanding that
> this is not the purpose of BIP32?
>
> Multisig wallets (like Electrum) have created a big mess too, on
> purpose or no, I don't know, but multisig is for different parties
> involved, not just one
>
>
> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>> I don’t know about Electrum but many wallets validate the English words, 
>> which helps in catching typos.
>>
>> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t 
>> even let you freely type characters; you have to select words from a list.
>>
>> So although the standard technically allows what you say, if you use 
>> anything other than 12, 16 or 24 English words, you’ll have fewer wallets to 
>> choose from.
>>
>> I think it’s better to come up with a new standard than trying to patch 
>> BIP-39 at this point, which is why I brought it up.
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans  
>>>  het volgende geschreven:
>>>
>>> "Very few wallets support anything other than English"
>>>
>>> By support do you mean allow recovery, validation or generation or all 
>>> three? For if you can freely type a phrase in (such as Electrum), or even 
>>> word by word, then the likely-hood is it is supported if they remembered to 
>>> normalize.
>>>
>>> Seed generation in BIP0039 requires no dictionary what-so-ever! So 
>>> there is no word list to lose in the first place. Your funds are accessible 
>>> with just the characters and the algorithm as described in BIP0039.
>>>
>>> But your proposal is a million miles away from simply adding some 
>>> standard in-language names to some word lists feels like it's derailing the 
>>> OP's simple proposal. Maybe start own email chain about it.
>>>
>>> Alan
>>>
>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
>>> 
>>>  wrote:
>>> I’m not a fan of language specific word lists within the current BIP-39 
>>> standard. Very few wallets support anything other than English, which can 
>>> lead to vendor lock-in and long term loss of funds if a rare non-English 
>>> wallet disappears.
>>>
>>> However, because people can memorize things better in their native 
>>> tongue, supporting multiple languages seems quite useful.
>>>
>>> I would prefer a new standard where words are mapped to integers rather 
>>> than to a literal string. For each language a mapping from words to 
>>> integers would be published. In addition to that, there would be a mapping 
>>> from original language words to matching (in terms of integer value, not 
>>> meaning) English words that people can print on an A4 paper. This would 
>>> allow them to enter a mnemonic into e.g. a hardware wallet that only 
>>> support English. Such lists are more likely to be around 100 years from now 
>>> than some ancient piece of software.
>>>
>>> This would not work with the current BIP-39 (duress) password, but this 
>>> feature could be replaced by appending words (with or without a checksum 
>>> for that addition).
>>>
>>> A replacement for BIP-39 would be a good opportunity to produce a 
>>> better English dictionary as Nic Johnson suggested a while ago:
>>> • all words are 4-8 characters
>>> • all 4-character prefixes are unique (very useful for hardware 
>>> wallets)
>>> • no two words have edit distance < 2
>>>
>>> Wallets need to be able to distinguish between the old and new 
>>> standard, so un-upgraded BIP 39 wallets should consider all new mnemonics 
>>> invalid. At the same time, some new wallets may not wish 

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

[nullius via bitcoin-dev]

On 2018-01-05 at 16:04:10 +, Sjors Provoost  
wrote:
I’m not a fan of language specific word lists within the current BIP-39 
standard. Very few wallets support anything other than English, which 
can lead to vendor lock-in and long term loss of funds if a rare 
non-English wallet disappears.


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


I would prefer a new standard [...] A replacement for BIP-39 [...]

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


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




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


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


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


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


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

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

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


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


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


Finally, aside:  In the discussion at SLIP repository issue #103, I see 
mention of m-of-n .  I have been mentally whiteboarding just such an 
application involving mnemonics.  Watch for it.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:

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

[Aymeric Vitte via bitcoin-dev]

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

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

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

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

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


Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
> I don’t know about Electrum but many wallets validate the English words, 
> which helps in catching typos.
>
> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even 
> let you freely type characters; you have to select words from a list.
>
> So although the standard technically allows what you say, if you use anything 
> other than 12, 16 or 24 English words, you’ll have fewer wallets to choose 
> from.
>
> I think it’s better to come up with a new standard than trying to patch 
> BIP-39 at this point, which is why I brought it up.
>
> Sjors
>
>> Op 5 jan. 2018, om 17:27 heeft Alan Evans  het 
>> volgende geschreven:
>>
>> "Very few wallets support anything other than English"
>>
>> By support do you mean allow recovery, validation or generation or all 
>> three? For if you can freely type a phrase in (such as Electrum), or even 
>> word by word, then the likely-hood is it is supported if they remembered to 
>> normalize.
>>
>> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is 
>> no word list to lose in the first place. Your funds are accessible with just 
>> the characters and the algorithm as described in BIP0039.
>>
>> But your proposal is a million miles away from simply adding some standard 
>> in-language names to some word lists feels like it's derailing the OP's 
>> simple proposal. Maybe start own email chain about it.
>>
>> Alan
>>
>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
>>  wrote:
>> I’m not a fan of language specific word lists within the current BIP-39 
>> standard. Very few wallets support anything other than English, which can 
>> lead to vendor lock-in and long term loss of funds if a rare non-English 
>> wallet disappears.
>>
>> However, because people can memorize things better in their native tongue, 
>> supporting multiple languages seems quite useful.
>>
>> I would prefer a new standard where words are mapped to integers rather than 
>> to a literal string. For each language a mapping from words to integers 
>> would be published. In addition to that, there would be a mapping from 
>> original language words to matching (in terms of integer value, not meaning) 
>> English words that people can print on an A4 paper. This would allow them to 
>> enter a mnemonic into e.g. a hardware wallet that only support English. Such 
>> lists are more likely to be around 100 years from now than some ancient 
>> piece of software.
>>
>> This would not work with the current BIP-39 (duress) password, but this 
>> feature could be replaced by appending words (with or without a checksum for 
>> that addition).
>>
>> A replacement for BIP-39 would be a good opportunity to produce a better 
>> English dictionary as Nic Johnson suggested a while ago:
>> • all words are 4-8 characters
>> • all 4-character prefixes are unique (very useful for hardware 
>> wallets)
>> • no two words have edit distance < 2
>>
>> Wallets need to be able to distinguish between the old and new standard, so 
>> un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the 
>> same time, some new wallets may not wish to support BIP39. They shouldn't be 
>> burdened with storing the old word list.
>>
>> A solution is to sort the new word list such that reused words appear first. 
>> When generating a mnemonic, at least one word unique to the new list must be 
>> present. A wallet only needs to know the index of the last BIP39 overlapping 
>> word. They reject a proposed mnemonic if none of the elements use a word 
>> with a higher index.
>>
>> For my above point and some related ideas, see: 
>> https://github.com/satoshilabs/slips/issues/103
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
>>>  het volgende geschreven:
>>>
>>> I propose and request as an enhancement that the BIP 39 wordlist set should 
>>> specify canonical native language strings to identify each wordlist, as 
>>> well as short ASCII language codes.  At present, the languages are 
>>> identified only by their names in English.
>>>
>>> Strings properly vetted and recommended by native speakers should 
>>> 

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

[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

> Op 5 jan. 2018, om 17:27 heeft Alan Evans  het 
> volgende geschreven:
> 
> "Very few wallets support anything other than English"
> 
> By support do you mean allow recovery, validation or generation or all three? 
> For if you can freely type a phrase in (such as Electrum), or even word by 
> word, then the likely-hood is it is supported if they remembered to normalize.
> 
> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is 
> no word list to lose in the first place. Your funds are accessible with just 
> the characters and the algorithm as described in BIP0039.
> 
> But your proposal is a million miles away from simply adding some standard 
> in-language names to some word lists feels like it's derailing the OP's 
> simple proposal. Maybe start own email chain about it.
> 
> Alan
> 
> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev 
>  wrote:
> I’m not a fan of language specific word lists within the current BIP-39 
> standard. Very few wallets support anything other than English, which can 
> lead to vendor lock-in and long term loss of funds if a rare non-English 
> wallet disappears.
> 
> However, because people can memorize things better in their native tongue, 
> supporting multiple languages seems quite useful.
> 
> I would prefer a new standard where words are mapped to integers rather than 
> to a literal string. For each language a mapping from words to integers would 
> be published. In addition to that, there would be a mapping from original 
> language words to matching (in terms of integer value, not meaning) English 
> words that people can print on an A4 paper. This would allow them to enter a 
> mnemonic into e.g. a hardware wallet that only support English. Such lists 
> are more likely to be around 100 years from now than some ancient piece of 
> software.
> 
> This would not work with the current BIP-39 (duress) password, but this 
> feature could be replaced by appending words (with or without a checksum for 
> that addition).
> 
> A replacement for BIP-39 would be a good opportunity to produce a better 
> English dictionary as Nic Johnson suggested a while ago:
> • all words are 4-8 characters
> • all 4-character prefixes are unique (very useful for hardware 
> wallets)
> • no two words have edit distance < 2
> 
> Wallets need to be able to distinguish between the old and new standard, so 
> un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the 
> same time, some new wallets may not wish to support BIP39. They shouldn't be 
> burdened with storing the old word list.
> 
> A solution is to sort the new word list such that reused words appear first. 
> When generating a mnemonic, at least one word unique to the new list must be 
> present. A wallet only needs to know the index of the last BIP39 overlapping 
> word. They reject a proposed mnemonic if none of the elements use a word with 
> a higher index.
> 
> For my above point and some related ideas, see: 
> https://github.com/satoshilabs/slips/issues/103
> 
> Sjors
> 
> > Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
> >  het volgende geschreven:
> >
> > I propose and request as an enhancement that the BIP 39 wordlist set should 
> > specify canonical native language strings to identify each wordlist, as 
> > well as short ASCII language codes.  At present, the languages are 
> > identified only by their names in English.
> >
> > Strings properly vetted and recommended by native speakers should 
> > facilitate language identification in user interface options or menus.  
> > Specification of language identifier strings would also promote interface 
> > consistency between implementations; this may be important if a user 
> > creates a mnemonic in Implementation A, then restores a wallet using that 
> > mnemonic in Implementation B.
> >
> > As an independent implementer who does not know *all* these different 
> > languages, I monkey-pasted language-native strings from a popular wiki 
> > site.  I cannot guarantee that they be all accurate, sensible, or even 
> > non-embarrassing.
> >
> > https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
> > ```
> >   LANG(english,   u8"English","en",   ascii_space ),
> >   

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

[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 while ago:
• all words are 4-8 characters
• all 4-character prefixes are unique (very useful for hardware wallets)
• no two words have edit distance < 2

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

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

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

Sjors

> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev 
>  het volgende geschreven:
> 
> I propose and request as an enhancement that the BIP 39 wordlist set should 
> specify canonical native language strings to identify each wordlist, as well 
> as short ASCII language codes.  At present, the languages are identified only 
> by their names in English.
> 
> Strings properly vetted and recommended by native speakers should facilitate 
> language identification in user interface options or menus.  Specification of 
> language identifier strings would also promote interface consistency between 
> implementations; this may be important if a user creates a mnemonic in 
> Implementation A, then restores a wallet using that mnemonic in 
> Implementation B.
> 
> As an independent implementer who does not know *all* these different 
> languages, I monkey-pasted language-native strings from a popular wiki site.  
> I cannot guarantee that they be all accurate, sensible, or even 
> non-embarrassing.
> 
> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
> ```
>   LANG(english,   u8"English","en",   ascii_space ),
>   LANG(chinese_simplified,u8"汉语", "zh-CN",ascii_space ),
>   LANG(chinese_traditional,   u8"漢語", "zh-TW",ascii_space ),
>   LANG(french,u8"Français",   "fr",   ascii_space ),
>   LANG(italian,   u8"Italiano",   "it",   ascii_space ),
>   LANG(japanese,  u8"日本語","ja",   u8"\u3000"  ),
>   LANG(korean,u8"한국어","ko",   ascii_space ),
>   LANG(spanish,   u8"Español","es",   ascii_space )
> ```
> 
> Per the comment at #L85 of the quoted file, I also know that for my short 
> identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar 
> as Hong Kong uses Traditional; and overseas Chinese may use either.  For 
> differentiating the two Chinese writing variants, are there any appropriate 
> standardized or customary short ASCII language IDs similar to ISO 3166-1 
> alpha-2 which are purely linguistic, and not fit to present-day political 
> boundaries?
> 
> My general suggestion is that the specification of appropriate strings in 
> bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for 
> accepting new wordlists.  My specific request is that such strings be 
> ascertained for the wordlists already existing, preferably from the persons 
> involved in the original pull requests therefor.
> 
> Should this proposal be “concept ACKed” by appropriate parties, then I may 
> open a pull request suggesting an appropriate format for specifying this 
> information in the repository.  However, I will must needs leave the vetting 
> of appropriate strings to native speakers or 

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

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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev