Re: [bitcoin-dev] Bech32 and P2SH²

[Gregory Maxwell via bitcoin-dev]

P2SH^2 wasn't a serious proposal-- I just suggested it as a thought
experiment. I don't think it offers much useful in the context of
Bitcoin today. Particularly since weight calculations have made output
space relatively more expensive and fees are at quite non-negligible
rates interest in "storing data" in outputs should at least not be
increasing.

Moreover, unfortunately, people already rushed bech32 to market in
advance of practically any public review-- regrettable but it is what
it is... I don't think adding more address diversity at this time
wouldn't be good for the ecosystem.

What we might want to do is consider working on an address-next
proposal that has an explicit timeframe of N years out, and very loud
don't deploy this--- layered hashing is just one very minor slightly
nice to have... things like coded expiration times, abilities to have
amounts under checksum, etc. are probably more worth consideration.



On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev
 wrote:
> I know I'm super-late to bring this up, but was there a reason Bech32 omitted
> the previously-discussed P2SH² improvements? Since deployment isn't too
> widespread yet, maybe it'd be worth a quick revision to add this?
>
> For those unfamiliar with the concept, the idea is to have the address include
> the *single* SHA256 hash of the public key or script, rather than
> RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would then
> perform the second hash to produce the output. Doing this would in the future
> enable relaying the "middle-hash" as a way to prove the final hash is in fact
> a hash itself, thereby proving it is not embedded data spam.
>
> Bech32 seems like a huge missed opportunity to add this, since everyone will
> probably be upgrading to it at some point.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bech32 and P2SH²

[Luke Dashjr via bitcoin-dev]

I've posted an initial draft of a possible Bech32 revision/replacement here:

https://github.com/luke-jr/bips/blob/new_bech32_p2sh2/bip-bech32-p2sh2.mediawiki

On Thursday 04 January 2018 2:23:05 PM Luke Dashjr via bitcoin-dev wrote:
> I know I'm super-late to bring this up, but was there a reason Bech32
> omitted the previously-discussed P2SH² improvements? Since deployment
> isn't too widespread yet, maybe it'd be worth a quick revision to add
> this?
> 
> For those unfamiliar with the concept, the idea is to have the address
> include the *single* SHA256 hash of the public key or script, rather than
> RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would then
> perform the second hash to produce the output. Doing this would in the
> future enable relaying the "middle-hash" as a way to prove the final hash
> is in fact a hash itself, thereby proving it is not embedded data spam.
> 
> Bech32 seems like a huge missed opportunity to add this, since everyone
> will probably be upgrading to it at some point.
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 to support BIP39. 
>>> They shouldn't be burdened with storing the old word list.
>>>
>>

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:


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

Further discussio

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 
>>> facilitate language identification in user interface options or menus.  
>>> Specification of language iden

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 ),
> >   LANG(chinese_simplified,u8"汉语", "zh-CN",ascii_space ),
> >   LANG(chinese_traditional,   u8"漢語", "zh-T

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 experts in the respective 
> languages.
>

[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