Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BCF7994B for ; Fri, 5 Jan 2018 18:08:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7926A7 for ; Fri, 5 Jan 2018 18:08:32 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id 9so3908081wme.4 for ; Fri, 05 Jan 2018 10:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=8b7K4Cl/nPmNWdBboj6SRgzJ44shyyj+G8dxUOEgz60=; b=k80fmlG1Hbgp3MlH0aIUxgaw+gXhAes1UeVQVSE6vyhfTVUPvxgOgTwQN8oCqzG72H pCctondedi32WHjpu/GMQxDg/20D0BxglqEAQVcR6qV4jjK3Um8Lk+ZpY1AlPaJqIbvv aXHQWWeqFrWxW6XF786CqH+7uZrvnrPjTBcfdK3HpCjQLz28O7Vx689mze4lHCT+gxDV ZJTy58Myf6DcEuH3XxvMqS+H4livicYDPqzF25ehdOHWvv+MRY/juq/ZrtgNYPFqAZYU OXWHeFsiBgDXq2XLSB8fNODc1nlXilcZKiUsdC5NYTy/ZnKi4eoDK2SgEeaFN7W84eyQ UUqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8b7K4Cl/nPmNWdBboj6SRgzJ44shyyj+G8dxUOEgz60=; b=Arf53lZ+cF6i3SgcgVBdU1q9sAm8R9ejmPM7OKmj8U5ZC49FWg8+62BxrbORU89vSc 4W1sB8n8yZu1NLF6UlhOVfR68srkCGoCEdtxHaYdDt0rF/TDX2eBfKslF2EXvuFaANwR 2jMD9/aPY8jB6mNZUQftmgpzETrh4JRGsMpjW+6LlvcRb85SECPveNmRaUtSY14VZ/Pt 1RM/EfF0SE6GnsRHGq+YYzMP57PNTPiEM2x045KY2eV1sAjaj5Kb/hsciu+WaWU7rP2d KzmHMYBXs9yoFauY8J0XY8JKWeRdnh92bBPEBrq6NmxfwqvGxiqnCpKN/1dYenhKqrOe DUSw== X-Gm-Message-State: AKGB3mIrhHkadbOddp+hPgvSwFrIJ2oJcyZD0ACR+WHBnzrqPacJkhTI 2zsH2TN6VlZeveeyn7ijCB4= X-Google-Smtp-Source: ACJfBots3Q/SxQY+2xjqSpb1GA5iJXd9X/XiEmP1WUNmbWmV71QUrDccOtbEsWS0+apFjuZqHof3TA== X-Received: by 10.80.180.168 with SMTP id w37mr5344021edd.122.1515175711391; Fri, 05 Jan 2018 10:08:31 -0800 (PST) Received: from ?IPv6:2a01:cb1d:5c:1600:4871:bf04:d8f5:dae4? ([2a01:cb1d:5c:1600:4871:bf04:d8f5:dae4]) by smtp.googlemail.com with ESMTPSA id f11sm4265990edf.28.2018.01.05.10.08.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 10:08:30 -0800 (PST) To: Sjors Provoost , Bitcoin Protocol Discussion , Alan Evans References: <57f5fcd8644c6f6472cd6a91144a6152@nym.zone> <2A39F6D7-CDF9-4624-BE0A-22C809C8B68C@sprovoost.nl> From: Aymeric Vitte Message-ID: Date: Fri, 5 Jan 2018 19:08:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <2A39F6D7-CDF9-4624-BE0A-22C809C8B68C@sprovoost.nl> Content-Type: multipart/alternative; boundary="------------DB319C52B43C3490ACA8382F" Content-Language: fr X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 18:08:34 -0000 This is a multi-part message in MIME format. --------------DB319C52B43C3490ACA8382F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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) =46rom 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 =C3=A0 18:13, Sjors Provoost via bitcoin-dev a =C3=A9crit=C2= =A0: > I don=E2=80=99t know about Electrum but many wallets validate the Engli= sh words, which helps in catching typos. > > Hardware wallets without a full keyboard, like the Ledger Nano S, won=E2= =80=99t even let you freely type characters; you have to select words fro= m a list. > > So although the standard technically allows what you say, if you use an= ything other than 12, 16 or 24 English words, you=E2=80=99ll have fewer w= allets to choose from. > > I think it=E2=80=99s 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 eve= n word by word, then the likely-hood is it is supported if they remembere= d to normalize. >> >> Seed generation in BIP0039 requires no dictionary what-so-ever! So the= re 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 stan= dard in-language names to some word lists feels like it's derailing the O= P'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=E2=80=99m not a fan of language specific word lists within the curre= nt 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 n= on-English wallet disappears. >> >> However, because people can memorize things better in their native ton= gue, supporting multiple languages seems quite useful. >> >> I would prefer a new standard where words are mapped to integers rathe= r than to a literal string. For each language a mapping from words to int= egers would be published. In addition to that, there would be a mapping f= rom original language words to matching (in terms of integer value, not m= eaning) English words that people can print on an A4 paper. This would al= low them to enter a mnemonic into e.g. a hardware wallet that only suppor= t English. Such lists are more likely to be around 100 years from now tha= n some ancient piece of software. >> >> This would not work with the current BIP-39 (duress) password, but thi= s feature could be replaced by appending words (with or without a checksu= m for that addition). >> >> A replacement for BIP-39 would be a good opportunity to produce a bett= er English dictionary as Nic Johnson suggested a while ago: >> =E2=80=A2 all words are 4-8 characters >> =E2=80=A2 all 4-character prefixes are unique (very useful for= hardware wallets) >> =E2=80=A2 no two words have edit distance < 2 >> >> Wallets need to be able to distinguish between the old and new standar= d, so un-upgraded BIP 39 wallets should consider all new mnemonics invali= d. 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 li= st must be present. A wallet only needs to know the index of the last BIP= 39 overlapping word. They reject a proposed mnemonic if none of the eleme= nts use a word with a higher index. >> >> For my above point and some related ideas, see: https://github.com/sat= oshilabs/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 wordlis= t, 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 fac= ilitate language identification in user interface options or menus. Spec= ification of language identifier strings would also promote interface con= sistency between implementations; this may be important if a user creates= a mnemonic in Implementation A, then restores a wallet using that mnemon= ic 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 s= ite. I cannot guarantee that they be all accurate, sensible, or even non= -embarrassing. >>> >>> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc0= 62dfc3f0db2c6/easyseed.c#L99 >>> ``` >>> LANG(english, u8"English", "en", ascii_s= pace ), >>> LANG(chinese_simplified, u8"=E6=B1=89=E8=AF=AD", "zh-CN"= ,ascii_space ), >>> LANG(chinese_traditional, u8"=E6=BC=A2=E8=AA=9E", "zh-TW"= ,ascii_space ), >>> LANG(french, u8"Fran=C3=A7ais", "fr", as= cii_space ), >>> LANG(italian, u8"Italiano", "it", ascii_s= pace ), >>> LANG(japanese, u8"=E6=97=A5=E6=9C=AC=E8=AA=9E"= , "ja", u8"\u3000" ), >>> LANG(korean, u8"=ED=95=9C=EA=B5=AD=EC=96=B4"= , "ko", ascii_space ), >>> LANG(spanish, u8"Espa=C3=B1ol", "es", as= cii_space ) >>> ``` >>> >>> Per the comment at #L85 of the quoted file, I also know that for my s= hort identifiers for Chinese, =E2=80=9Czh-CN=E2=80=9D and =E2=80=9Czh-TW=E2= =80=9D, are imprecise at best=E2=80=94insofar as Hong Kong uses Tradition= al; and overseas Chinese may use either. For differentiating the two Chi= nese writing variants, are there any appropriate standardized or customar= y 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 string= s in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the proc= ess for accepting new wordlists. My specific request is that such string= s be ascertained for the wordlists already existing, preferably from the = persons involved in the original pull requests therefor. >>> >>> Should this proposal be =E2=80=9Cconcept ACKed=E2=80=9D by appropriat= e parties, then I may open a pull request suggesting an appropriate forma= t for specifying this information in the repository. However, I will mus= t needs leave the vetting of appropriate strings to native speakers or ex= perts in the respective languages. >>> >>> Prior references: The wordlist additions at PRs #92, #130 (Japanese)= ; #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Ita= lian); #570 (Korean); #621 (Indonesian, *proposed*, open). >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=20 Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac= tions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.o= rg Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms --------------DB319C52B43C3490ACA8382F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

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

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

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

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


Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
I don’t know about Electrum but many wallets validate the English words, which helps in catching typos.

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

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

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

Sjors


Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans@gmail.com> het volgende geschreven:

"Very few wallets support anything other than English"

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

Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.

But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.

Alan

On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I’m not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.

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

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

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

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

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

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

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

Sjors


Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:

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

Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus.  Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.

As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site.  I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.

https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
      LANG(english,                   u8"English",    "en",   ascii_space ),
      LANG(chinese_simplified,        u8"汉语", "zh-CN",ascii_space ),
      LANG(chinese_traditional,       u8"漢語", "zh-TW",ascii_space ),
      LANG(french,                    u8"Français",   "fr",   ascii_space ),
      LANG(italian,                   u8"Italiano",   "it",   ascii_space ),
      LANG(japanese,                  u8"日本語",        "ja",   u8"\u3000"  ),
      LANG(korean,                    u8"한국어",        "ko",   ascii_space ),
      LANG(spanish,                   u8"Español",    "es",   ascii_space )
```

Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar as Hong Kong uses Traditional; and overseas Chinese may use either.  For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?

My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists.  My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.

Should this proposal be “concept ACKed” by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository.  However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.

Prior references:  The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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


<signature.asc>


      

      

      

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


    

    

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

  


--------------DB319C52B43C3490ACA8382F--