path: root/81/a1facb7cd822d1a82f5d5175d449f19048f1a8

Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CE3569B9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Jan 2018 17:40:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com
	[209.85.128.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79791A7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Jan 2018 17:40:44 +0000 (UTC)
Received: by mail-wr0-f173.google.com with SMTP id o15so6958618wrf.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Jan 2018 09:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:cc:references:from:message-id:date:user-agent
	:mime-version:in-reply-to:content-language;
	bh=b1KP6hKVBQ6fGXXpivUNGTFzgHC22TcCyu+MwQsvUvY=;
	b=XIKbRKOYZOfXxOrrMCV+dc6VPnqiDLNWSdAiX+MUD9wsQtdAAq5ihQ0P+5HItfSZa6
	qPYMNn+GwSzr9ydxWZA+9rjLhOfAJoeagHbj/HNLXCEKs0C+/xrxlw6AsdRY+2GK19A/
	3XE1vHRU1vvTLXABEqUPKvLZOAV4nzdSLmgsf1L6JrlgjrM5oOOHhwOFVU4mtW2ooVx0
	hVM+RnWE0AQ7zIyQiKVAWNXUut4eM41F09L7oQcVbj3JIdfi+0J6eUb0VSjNpisKRbtX
	1zDjmVCRR8js+W8kBv8PtE8HVIIs+vAWytc2qHH726DoTbqm1CIdZbuoNs4NrhF0pd+4
	l6Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:cc:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-language;
	bh=b1KP6hKVBQ6fGXXpivUNGTFzgHC22TcCyu+MwQsvUvY=;
	b=JcKFCrv5iEtFxxojKj5EYQE1OEzKC25E6N/z8wlbkiJoNzxmLlerolROUJYwJxyX/+
	RGj+sOPxvrASgKTc2dux9ZL/GtibLTQLVVxzWJAEZJUWShwPdCAZcJruTnGgpVaWL/j1
	6ZYy9FD/57sGi89P4J50LsUKQY8gd4xEz3z6FcczV72GZEhctWtPykaSY+/pDFX1qrT8
	Jmmnyv6x91ptmvjEEOaXWvTYsYfTa3D34LSg8ZFl29Nc6ESv2LA8CfYApsJx3gFDjPeS
	9cigjzh83XsOMM26JS57RK6tNHuQf117cTM0XNGoUd9iGB9V1SBCc0QVvBpkOClwo6NV
	eCCQ==
X-Gm-Message-State: AKGB3mJTUv0BlQrHxBWtqEw80i3Ux0reqBgM/RWQnb0LNwE7ah18BN7K
	QJgZwUMMeaSpYfLone0jKh4KvQ==
X-Google-Smtp-Source: ACJfBouGtcp11v51L0MWc2uZfT3Iz61/s852mkIcTMFGDBvLZpHXBpQI8C8kP2VijDblPAABSZY6ug==
X-Received: by 10.223.208.206 with SMTP id z14mr6132840wrh.109.1515260442520; 
	Sat, 06 Jan 2018 09:40:42 -0800 (PST)
Received: from ?IPv6:2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17?
	([2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17])
	by smtp.googlemail.com with ESMTPSA id
	g60sm4276029wrd.92.2018.01.06.09.40.40
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 06 Jan 2018 09:40:41 -0800 (PST)
To: Alan Evans <thealanevans@gmail.com>
References: <57f5fcd8644c6f6472cd6a91144a6152@nym.zone>
	<BB3FA46E-AA09-4A60-9D0F-8E350015E107@sprovoost.nl>
	<CALPhJax=53dLL9+JDKJC7NdEFFRB2kgKiECSh8PUMzrr2KxWuQ@mail.gmail.com>
	<2A39F6D7-CDF9-4624-BE0A-22C809C8B68C@sprovoost.nl>
	<af76eb48-8ef9-59b5-f7cd-dd3e45277deb@gmail.com>
	<CALPhJaxzayykMMxaa421kfu6QQ77JD7bZJk8+dXT4qSqK_eABg@mail.gmail.com>
	<258487be-0b5b-f5fc-e63c-4de7c0e1c874@gmail.com>
	<CALPhJawP7hjucR6X3gpTxCxK+awMT9iArELZYFy_zffCGgVMEw@mail.gmail.com>
	<58C8F1BA-B9A1-4525-BCC9-BF4CEDC87E1B@sprovoost.nl>
	<a3e10fe7-ed9c-bb58-bf12-d0aeda2827e4@gmail.com>
	<a2e8b3e2-b444-039c-c51e-43294a3437c9@gmail.com>
	<CALPhJaz1wU8y6KxZipREjus8WbHpwpyYjyMwgj5x-tTodxpjCQ@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <122d7820-3968-0c53-0156-23bf94a54ce2@gmail.com>
Date: Sat, 6 Jan 2018 18:40:40 +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: <CALPhJaz1wU8y6KxZipREjus8WbHpwpyYjyMwgj5x-tTodxpjCQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------F9B669A59FD500FCB6DFD099"
Content-Language: fr
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 08 Jan 2018 04:11:40 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jan 2018 17:40:47 -0000

This is a multi-part message in MIME format.
--------------F9B669A59FD500FCB6DFD099
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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

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

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

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

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

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

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

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

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

Le 06/01/2018 à 16:00, Alan Evans a écrit :
> You're mistaken. BIP32 does not require a particular length. It
> recommends:
>
>   * Generate a seed byte sequence S of a chosen length (between 128
>     and 512 bits; 256 bits is advised) from a (P)RNG
>
> But BIP39 produces a 64 byte seed:
>
> The length of the derived key is 512 bits (= 64 bytes).
>
> If you don't believe me, why don't you just try it? That seed will
> derive the same keys as that mnemonic, it's a real example.
>
> ---------
>
> About printing, there is a huge security risk involved in printing
> anything. Networks, printers may have memory. People will print to PDF
> when they don't have a printer on hand. Mobile users often can't print.
>
> I wrote mine down, by hand, generated from an offline computer booted
> with a readonly OS. 
>
> Feel free to produce a recommendation to replace BIP39/32/44 if you
> like, but it's not broken just because someone had trouble using your
> tool/following your instructions. And no offence but I'd be wary using
> a tool from someone who doesn't read the BIPs closely yet is so
> confident about how other people are wrong.
>
>
> On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
>     bytes as your wrote below, which probably corresponds to xprv,
>     which is
>     another misleading element of BIP39
>
>
>     Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
>     > The fact is indeed that "we should really find a way to overhaul
>     this
>     > whole BIP 39 / 43/ 44 etc ad hoc mess"
>     >
>     > Because the git example I provided is about someone that knows (to a
>     > certain extent) what he is doing, then made a mistake for the
>     > destination address, which is not related to this discussion
>     >
>     > This just shows how complicate it can become even for people knowing
>     > this to retrieve their wallet and how wallets made it "the easy
>     way" (ie
>     > bip39, 44, multisig...)
>     >
>     > If people prefer to store mnemonics, why not, but "writing down"
>     in both
>     > messages above is not accurate, you would better print it and
>     cut it in
>     > n pieces if you like, then the point of using mnemonics that you
>     can't
>     > remember more than an hex string still remains useless from my
>     standpoint
>     >
>     > Beside the theory we should look now if BIP39 & all brought more
>     good
>     > than the contrary in practice, I think that the later wins
>     >
>     >
>     > Le 05/01/2018 à 21:38, Sjors Provoost a écrit :
>     >> Hi Alan,
>     >>
>     >> The Github issue is arguably unrelated, which is why I put it
>     at the end and said “some related”.
>     >>
>     >> However it does all tie together; we should really find a way
>     to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess, ideally in
>     a way that even Bitcoin Core would be willing to use it. When you
>     change the word list, it’s best to change everything else at the
>     same time. Otherwise you’d have too many different standards,
>     which is a pain for wallets to implement.
>     >>
>     >> I share your view than a mnemonic is better than a bunch of hex
>     numbers. It’s easier to memorize and easier to write down. Some
>     people don’t like it when users write down phrases, but they’re
>     much, much more likely to lose their coins than some burglar to
>     find the piece of paper. My issue is only with the way derivation
>     currently works.
>     >>
>     >> Sjors
>     >>
>     >>> Op 5 jan. 2018, om 21:05 heeft Alan Evans
>     <thealanevans@gmail.com <mailto:thealanevans@gmail.com>> het
>     volgende geschreven:
>     >>>
>     >>> Taking it off the board. I can't read all of that issue.
>     BIP0039 mnemonic generates a seed. Everything past there to do
>     with addresses (BIP32/44/49/141 whatever) is the same as if you
>     started with the seed. So you can't blaim BIP0039 for that
>     person's misunderstanding, and the way different wallets use
>     different derivation paths.
>     >>>
>     >>> If someone has a BIP0039 mnemonic and would rather back up the
>     seed, they can go ahead. But one tiny mistake in writing it down
>     and you may have a hell of a time finding out what's wrong as
>     every seed is valid. A mistake in writing down words is far harder
>     to make. You can also memorize a mnemonic (hence the name), the
>     average person cannot memorize a seed.
>     >>>
>     >>> fork canal mad beyond spike pool expire fuel region impose
>     ceiling video
>     >>>
>     >>> vs:
>     >>>
>     >>>
>     f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
>     >>>
>     >>> But they lead to the same addresses.
>     >>>
>     >>> Need I say more?
>     >>>
>     >>>
>     >>> On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>     >>> No that's not, some parts of the answer might be but this
>     related, this just shows how people use wrongly BIP39 and
>     subsequent BIPs (and globally other things), misleading them,
>     while the advantage of using it is quite dubious compared to
>     backing up a seed, unless you can convince me of the contrary
>     >>>
>     >>> Le 05/01/2018 à 19:16, Alan Evans a écrit :
>     >>>> Sjors, well in Electrum, validation is optional, but English
>     only. As for the Ledger-S, that sounds like a Ledger problem.
>     >>>>
>     >>>> Aymeric, that is way off topic, did you reply to wrong email?
>     >>>>
>     >>>> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>     >>>> See: https://github.com/Ayms/bitcoin-transactions/issues/3
>     <https://github.com/Ayms/bitcoin-transactions/issues/3>
>     >>>>
>     >>>> OK, maybe it's my fault, I did not foresee this case, and now
>     it's working for p2sh (non segwit)
>     >>>> From my standpoint this just means that BIP39/44 stuff should
>     be eradicated (not BIP141 but see what happened...), this is of no
>     use, confusing people, doing dangerous things to recover
>     >>>> Really is it easier to save x words instead of a seed?
>     Knowing that people are creating several wallets not understanding
>     that this is not the purpose of BIP32?
>     >>>>
>     >>>> Multisig wallets (like Electrum) have created a big mess too,
>     on purpose or no, I don't know, but multisig is for different
>     parties involved, not just one
>     >>>>
>     >>>> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>     >>>>> I don’t know about Electrum but many wallets validate the
>     English words, which helps in catching typos.
>     >>>>>
>     >>>>> Hardware wallets without a full keyboard, like the Ledger
>     Nano S, won’t even let you freely type characters; you have to
>     select words from a list.
>     >>>>>
>     >>>>> So although the standard technically allows what you say, if
>     you use anything other than 12, 16 or 24 English words, you’ll
>     have fewer wallets to choose from.
>     >>>>>
>     >>>>> I think it’s better to come up with a new standard than
>     trying to patch BIP-39 at this point, which is why I brought it up.
>     >>>>>
>     >>>>> Sjors
>     >>>>>
>     >>>>>
>     >>>>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans
>     <thealanevans@gmail.com <mailto:thealanevans@gmail.com>>
>     >>>>>>  het volgende geschreven:
>     >>>>>>
>     >>>>>> "Very few wallets support anything other than English"
>     >>>>>>
>     >>>>>> By support do you mean allow recovery, validation or
>     generation or all three? For if you can freely type a phrase in
>     (such as Electrum), or even word by word, then the likely-hood is
>     it is supported if they remembered to normalize.
>     >>>>>>
>     >>>>>> Seed generation in BIP0039 requires no dictionary
>     what-so-ever! So there is no word list to lose in the first place.
>     Your funds are accessible with just the characters and the
>     algorithm as described in BIP0039.
>     >>>>>>
>     >>>>>> But your proposal is a million miles away from simply
>     adding some standard in-language names to some word lists feels
>     like it's derailing the OP's simple proposal. Maybe start own
>     email chain about it.
>     >>>>>>
>     >>>>>> Alan
>     >>>>>>
>     >>>>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev
>     >>>>>> <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>     >>>>>>  wrote:
>     >>>>>> I’m not a fan of language specific word lists within the
>     current BIP-39 standard. Very few wallets support anything other
>     than English, which can lead to vendor lock-in and long term loss
>     of funds if a rare non-English wallet disappears.
>     >>>>>>
>     >>>>>> However, because people can memorize things better in their
>     native tongue, supporting multiple languages seems quite useful.
>     >>>>>>
>     >>>>>> I would prefer a new standard where words are mapped to
>     integers rather than to a literal string. For each language a
>     mapping from words to integers would be published. In addition to
>     that, there would be a mapping from original language words to
>     matching (in terms of integer value, not meaning) English words
>     that people can print on an A4 paper. This would allow them to
>     enter a mnemonic into e.g. a hardware wallet that only support
>     English. Such lists are more likely to be around 100 years from
>     now than some ancient piece of software.
>     >>>>>>
>     >>>>>> This would not work with the current BIP-39 (duress)
>     password, but this feature could be replaced by appending words
>     (with or without a checksum for that addition).
>     >>>>>>
>     >>>>>> A replacement for BIP-39 would be a good opportunity to
>     produce a better English dictionary as Nic Johnson suggested a
>     while ago:
>     >>>>>>         • all words are 4-8 characters
>     >>>>>>         • all 4-character prefixes are unique (very useful
>     for hardware wallets)
>     >>>>>>         • no two words have edit distance < 2
>     >>>>>>
>     >>>>>> Wallets need to be able to distinguish between the old and
>     new standard, so un-upgraded BIP 39 wallets should consider all
>     new mnemonics invalid. At the same time, some new wallets may not
>     wish to support BIP39. They shouldn't be burdened with storing the
>     old word list.
>     >>>>>>
>     >>>>>> A solution is to sort the new word list such that reused
>     words appear first. When generating a mnemonic, at least one word
>     unique to the new list must be present. A wallet only needs to
>     know the index of the last BIP39 overlapping word. They reject a
>     proposed mnemonic if none of the elements use a word with a higher
>     index.
>     >>>>>>
>     >>>>>> For my above point and some related ideas, see:
>     >>>>>> https://github.com/satoshilabs/slips/issues/103
>     <https://github.com/satoshilabs/slips/issues/103>
>     >>>>>>
>     >>>>>>
>     >>>>>> Sjors
>     >>>>>>
>     >>>>>>
>     >>>>>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>>
>     >>>>>>>  het volgende geschreven:
>     >>>>>>>
>     >>>>>>> I propose and request as an enhancement that the BIP 39
>     wordlist set should specify canonical native language strings to
>     identify each wordlist, as well as short ASCII language codes.  At
>     present, the languages are identified only by their names in English.
>     >>>>>>>
>     >>>>>>> Strings properly vetted and recommended by native speakers
>     should facilitate language identification in user interface
>     options or menus.  Specification of language identifier strings
>     would also promote interface consistency between implementations;
>     this may be important if a user creates a mnemonic in
>     Implementation A, then restores a wallet using that mnemonic in
>     Implementation B.
>     >>>>>>>
>     >>>>>>> As an independent implementer who does not know *all*
>     these different languages, I monkey-pasted language-native strings
>     from a popular wiki site.  I cannot guarantee that they be all
>     accurate, sensible, or even non-embarrassing.
>     >>>>>>>
>     >>>>>>>
>     >>>>>>>
>     https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
>     <https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
>     >>>>>>>
>     >>>>>>> ```
>     >>>>>>>       LANG(english,                   u8"English",   
>     "en",   ascii_space ),
>     >>>>>>>       LANG(chinese_simplified,        u8"汉语",
>     "zh-CN",ascii_space ),
>     >>>>>>>       LANG(chinese_traditional,       u8"漢語",
>     "zh-TW",ascii_space ),
>     >>>>>>>       LANG(french,                    u8"Français", 
>      "fr",   ascii_space ),
>     >>>>>>>       LANG(italian,                   u8"Italiano", 
>      "it",   ascii_space ),
>     >>>>>>>       LANG(japanese,                  u8"日本語",       
>     "ja",   u8"\u3000"  ),
>     >>>>>>>       LANG(korean,                    u8"한국어",       
>     "ko",   ascii_space ),
>     >>>>>>>       LANG(spanish,                   u8"Español",   
>     "es",   ascii_space )
>     >>>>>>> ```
>     >>>>>>>
>     >>>>>>> Per the comment at #L85 of the quoted file, I also know
>     that for my short identifiers for Chinese, “zh-CN” and “zh-TW”,
>     are imprecise at best—insofar as Hong Kong uses Traditional; and
>     overseas Chinese may use either.  For differentiating the two
>     Chinese writing variants, are there any appropriate standardized
>     or customary short ASCII language IDs similar to ISO 3166-1
>     alpha-2 which are purely linguistic, and not fit to present-day
>     political boundaries?
>     >>>>>>>
>     >>>>>>> My general suggestion is that the specification of
>     appropriate strings in
>     >>>>>>> bitcoin:bips/bip-0039/bip-0039-wordlists.md
>     <http://bip-0039-wordlists.md>
>     >>>>>>>  be made part of the process for accepting new wordlists. 
>     My specific request is that such strings be ascertained for the
>     wordlists already existing, preferably from the persons involved
>     in the original pull requests therefor.
>     >>>>>>>
>     >>>>>>> Should this proposal be “concept ACKed” by appropriate
>     parties, then I may open a pull request suggesting an appropriate
>     format for specifying this information in the repository. 
>     However, I will must needs leave the vetting of appropriate
>     strings to native speakers or experts in the respective languages.
>     >>>>>>>
>     >>>>>>> Prior references:  The wordlist additions at PRs #92, #130
>     (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152
>     (French); #306 (Italian); #570 (Korean); #621 (Indonesian,
>     *proposed*, open).
>     >>>>>>> ______________________________
>     >>>>>>> _________________
>     >>>>>>> bitcoin-dev mailing list
>     >>>>>>>
>     >>>>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>>>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>     >>>>>> ______________________________
>     >>>>>> _________________
>     >>>>>> bitcoin-dev mailing list
>     >>>>>>
>     >>>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>> <signature.asc>
>     >>>>>>
>     >>>>> ______________________________
>     >>>>> _________________
>     >>>>> bitcoin-dev mailing list
>     >>>>>
>     >>>>> bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     >>>>>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>     >>>> --
>     >>>> Bitcoin transactions made simple:
>     >>>> https://github.com/Ayms/bitcoin-transactions
>     <https://github.com/Ayms/bitcoin-transactions>
>     >>>>
>     >>>> Zcash wallets made simple:
>     >>>> https://github.com/Ayms/zcash-wallets
>     <https://github.com/Ayms/zcash-wallets>
>     >>>>
>     >>>> Bitcoin wallets made simple:
>     >>>> https://github.com/Ayms/bitcoin-wallets
>     <https://github.com/Ayms/bitcoin-wallets>
>     >>>>
>     >>>> Get the torrent dynamic blocklist:
>     >>>> http://peersm.com/getblocklist
>     >>>>
>     >>>> Check the 10 M passwords list:
>     >>>> http://peersm.com/findmyass
>     >>>>
>     >>>> Anti-spies and private torrents, dynamic blocklist:
>     >>>> http://torrent-live.org
>     >>>>
>     >>>> Peersm :
>     >>>> http://www.peersm.com
>     >>>>
>     >>>> torrent-live:
>     >>>> https://github.com/Ayms/torrent-live
>     <https://github.com/Ayms/torrent-live>
>     >>>>
>     >>>> node-Tor :
>     >>>> https://www.github.com/Ayms/node-Tor
>     <https://www.github.com/Ayms/node-Tor>
>     >>>>
>     >>>> GitHub :
>     >>>> https://www.github.com/Ayms
>     >>>>
>     >>> --
>     >>> Bitcoin transactions made simple:
>     >>> https://github.com/Ayms/bitcoin-transactions
>     <https://github.com/Ayms/bitcoin-transactions>
>     >>>
>     >>> Zcash wallets made simple:
>     >>> https://github.com/Ayms/zcash-wallets
>     <https://github.com/Ayms/zcash-wallets>
>     >>>
>     >>> Bitcoin wallets made simple:
>     >>> https://github.com/Ayms/bitcoin-wallets
>     <https://github.com/Ayms/bitcoin-wallets>
>     >>>
>     >>> Get the torrent dynamic blocklist:
>     >>> http://peersm.com/getblocklist
>     >>>
>     >>> Check the 10 M passwords list:
>     >>> http://peersm.com/findmyass
>     >>>
>     >>> Anti-spies and private torrents, dynamic blocklist:
>     >>> http://torrent-live.org
>     >>>
>     >>> Peersm :
>     >>> http://www.peersm.com
>     >>>
>     >>> torrent-live:
>     >>> https://github.com/Ayms/torrent-live
>     <https://github.com/Ayms/torrent-live>
>     >>>
>     >>> node-Tor :
>     >>> https://www.github.com/Ayms/node-Tor
>     <https://www.github.com/Ayms/node-Tor>
>     >>>
>     >>> GitHub :
>     >>> https://www.github.com/Ayms
>     >>>
>
>     --
>     Bitcoin transactions made simple:
>     https://github.com/Ayms/bitcoin-transactions
>     <https://github.com/Ayms/bitcoin-transactions>
>     Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
>     <https://github.com/Ayms/zcash-wallets>
>     Bitcoin wallets made simple:
>     https://github.com/Ayms/bitcoin-wallets
>     <https://github.com/Ayms/bitcoin-wallets>
>     Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>     Check the 10 M passwords list: http://peersm.com/findmyass
>     Anti-spies and private torrents, dynamic blocklist:
>     http://torrent-live.org
>     Peersm : http://www.peersm.com
>     torrent-live: https://github.com/Ayms/torrent-live
>     node-Tor <https://github.com/Ayms/torrent-live%0Anode-Tor> :
>     https://www.github.com/Ayms/node-Tor
>     <https://www.github.com/Ayms/node-Tor>
>     GitHub : https://www.github.com/Ayms
>
>

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


--------------F9B669A59FD500FCB6DFD099
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Unfortunately, even "yourself" seems not to know what he is
      talking about (so imagine for other people, 256 bits is advised
      --&gt; 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</p>
    <p>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 <b>derived </b>key", not the
      seed), cf <a href="https://github.com/Ayms/bitcoin-wallets"
        rel="noreferrer" target="_blank">https://github.com/Ayms/<wbr>bitcoin-wallets</a>
      and even <a href="https://github.com/Ayms/zcash-wallets"
        rel="noreferrer" target="_blank">https://github.com/Ayms/zcash-<wbr>wallets
        (not official but https://github.com/zcash/zips/issues/95)<br>
      </a></p>
    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"<br>
    <br>
    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<br>
    <br>
    "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<br>
    <br>
    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<br>
    <br>
    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<br>
    <br>
    See this too
    <a class="moz-txt-link-freetext" href="https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887">https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887</a>,
    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...)<br>
    <br>
    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)<br>
    <br>
    <div class="moz-cite-prefix">Le 06/01/2018 à 16:00, Alan Evans a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CALPhJaz1wU8y6KxZipREjus8WbHpwpyYjyMwgj5x-tTodxpjCQ@mail.gmail.com">
      <div dir="ltr">
        <div>You're mistaken. BIP32 does not require a
          particular length. It recommends:
          <div><br>
          </div>
          <div>
            <ul
style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,system-ui,&quot;Segoe
              UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color
              Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI
              Symbol&quot;;font-size:16px">
              <li style="box-sizing:border-box">Generate a seed byte
                sequence S of a chosen length (between 128 and 512 bits;
                256 bits is advised) from a (P)RNG</li>
            </ul>
          </div>
          <div>But BIP39 produces a 64 byte seed:</div>
          <div><br>
          </div>
          <div><span
style="color:rgb(36,41,46);font-family:-apple-system,system-ui,&quot;Segoe
              UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color
              Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI
              Symbol&quot;;font-size:16px">The length of the derived key
              is 512 bits (= 64 bytes).</span><br>
          </div>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>---------</div>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>I wrote mine down, by hand, generated from an offline
            computer booted with a readonly OS. </div>
          <div><br>
          </div>
          <div>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.</div>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sat, Jan 6, 2018 at 6:57 AM, Aymeric
          Vitte <span dir="ltr">&lt;<a
              href="mailto:vitteaymeric@gmail.com" target="_blank"
              moz-do-not-send="true">vitteaymeric@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">And Alan,
            btw, a BIP32 seed is 32 bytes, then 64 characters, not 64<br>
            bytes as your wrote below, which probably corresponds to
            xprv, which is<br>
            another misleading element of BIP39<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :<br>
                &gt; The fact is indeed that "we should really find a
                way to overhaul this<br>
                &gt; whole BIP 39 / 43/ 44 etc ad hoc mess"<br>
                &gt;<br>
                &gt; Because the git example I provided is about someone
                that knows (to a<br>
                &gt; certain extent) what he is doing, then made a
                mistake for the<br>
                &gt; destination address, which is not related to this
                discussion<br>
                &gt;<br>
                &gt; This just shows how complicate it can become even
                for people knowing<br>
                &gt; this to retrieve their wallet and how wallets made
                it "the easy way" (ie<br>
                &gt; bip39, 44, multisig...)<br>
                &gt;<br>
                &gt; If people prefer to store mnemonics, why not, but
                "writing down" in both<br>
                &gt; messages above is not accurate, you would better
                print it and cut it in<br>
                &gt; n pieces if you like, then the point of using
                mnemonics that you can't<br>
                &gt; remember more than an hex string still remains
                useless from my standpoint<br>
                &gt;<br>
                &gt; Beside the theory we should look now if BIP39 &amp;
                all brought more good<br>
                &gt; than the contrary in practice, I think that the
                later wins<br>
                &gt;<br>
                &gt;<br>
                &gt; Le 05/01/2018 à 21:38, Sjors Provoost a écrit :<br>
                &gt;&gt; Hi Alan,<br>
                &gt;&gt;<br>
                &gt;&gt; The Github issue is arguably unrelated, which
                is why I put it at the end and said “some related”.<br>
                &gt;&gt;<br>
                &gt;&gt; However it does all tie together; we should
                really find a way to overhaul this whole BIP 39 / 43/ 44
                etc ad hoc mess, ideally in a way that even Bitcoin Core
                would be willing to use it. When you change the word
                list, it’s best to change everything else at the same
                time. Otherwise you’d have too many different standards,
                which is a pain for wallets to implement.<br>
                &gt;&gt;<br>
                &gt;&gt; I share your view than a mnemonic is better
                than a bunch of hex numbers. It’s easier to memorize and
                easier to write down. Some people don’t like it when
                users write down phrases, but they’re much, much more
                likely to lose their coins than some burglar to find the
                piece of paper. My issue is only with the way derivation
                currently works.<br>
                &gt;&gt;<br>
                &gt;&gt; Sjors<br>
                &gt;&gt;<br>
                &gt;&gt;&gt; Op 5 jan. 2018, om 21:05 heeft Alan Evans
                &lt;<a href="mailto:thealanevans@gmail.com"
                  moz-do-not-send="true">thealanevans@gmail.com</a>&gt;
                het volgende geschreven:<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Taking it off the board. I can't read all
                of that issue. BIP0039 mnemonic generates a seed.
                Everything past there to do with addresses
                (BIP32/44/49/141 whatever) is the same as if you started
                with the seed. So you can't blaim BIP0039 for that
                person's misunderstanding, and the way different wallets
                use different derivation paths.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; If someone has a BIP0039 mnemonic and would
                rather back up the seed, they can go ahead. But one tiny
                mistake in writing it down and you may have a hell of a
                time finding out what's wrong as every seed is valid. A
                mistake in writing down words is far harder to make. You
                can also memorize a mnemonic (hence the name), the
                average person cannot memorize a seed.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; fork canal mad beyond spike pool expire
                fuel region impose ceiling video<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; vs:<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; f54b80812b3a6f1834095370df82a2<wbr>123aece2d6089da67d7871477c0046<wbr>84fbc399a6155e53de0b783a9be638<wbr>8354846e51f59e4869984f0c554e64<wbr>69788c64<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; But they lead to the same addresses.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Need I say more?<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; On Fri, Jan 5, 2018 at 3:56 PM, Aymeric
                Vitte &lt;<a href="mailto:vitteaymeric@gmail.com"
                  moz-do-not-send="true">vitteaymeric@gmail.com</a>&gt;
                wrote:<br>
                &gt;&gt;&gt; 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<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Le 05/01/2018 à 19:16, Alan Evans a écrit :<br>
                &gt;&gt;&gt;&gt; Sjors, well in Electrum, validation is
                optional, but English only. As for the Ledger-S, that
                sounds like a Ledger problem.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Aymeric, that is way off topic, did you
                reply to wrong email?<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; On Fri, Jan 5, 2018 at 2:08 PM, Aymeric
                Vitte &lt;<a href="mailto:vitteaymeric@gmail.com"
                  moz-do-not-send="true">vitteaymeric@gmail.com</a>&gt;
                wrote:<br>
                &gt;&gt;&gt;&gt; See: <a
                  href="https://github.com/Ayms/bitcoin-transactions/issues/3"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions/issues/3</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; OK, maybe it's my fault, I did not
                foresee this case, and now it's working for p2sh (non
                segwit)<br>
                &gt;&gt;&gt;&gt; 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<br>
                &gt;&gt;&gt;&gt; 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?<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; 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<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Le 05/01/2018 à 18:13, Sjors Provoost
                via bitcoin-dev a écrit :<br>
                &gt;&gt;&gt;&gt;&gt; I don’t know about Electrum but
                many wallets validate the English words, which helps in
                catching typos.<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; Sjors<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; Op 5 jan. 2018, om 17:27 heeft
                Alan Evans &lt;<a href="mailto:thealanevans@gmail.com"
                  moz-do-not-send="true">thealanevans@gmail.com</a>&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;  het volgende geschreven:<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; "Very few wallets support
                anything other than English"<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; Alan<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; On Fri, Jan 5, 2018 at 12:04
                PM, Sjors Provoost via bitcoin-dev<br>
                &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;  wrote:<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; However, because people can
                memorize things better in their native tongue,
                supporting multiple languages seems quite useful.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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).<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; A replacement for BIP-39 would
                be a good opportunity to produce a better English
                dictionary as Nic Johnson suggested a while ago:<br>
                &gt;&gt;&gt;&gt;&gt;&gt;         • all words are 4-8
                characters<br>
                &gt;&gt;&gt;&gt;&gt;&gt;         • all 4-character
                prefixes are unique (very useful for hardware wallets)<br>
                &gt;&gt;&gt;&gt;&gt;&gt;         • no two words have
                edit distance &lt; 2<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; For my above point and some
                related ideas, see:<br>
                &gt;&gt;&gt;&gt;&gt;&gt; <a
                  href="https://github.com/satoshilabs/slips/issues/103"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/<wbr>satoshilabs/slips/issues/103</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; Sjors<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; Op 5 jan. 2018, om 14:58
                heeft nullius via bitcoin-dev &lt;<a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;  het volgende geschreven:<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a
href="https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/nym-zone/<wbr>easyseed/blob/<wbr>1a6e48bbdac9366d9d5d1912dc062d<wbr>fc3f0db2c6/easyseed.c#L99</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; ```<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(english,       
                           u8"English",    "en",   ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;     
                 LANG(chinese_simplified,        u8"汉语",
                "zh-CN",ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;     
                 LANG(chinese_traditional,       u8"漢語",
                "zh-TW",ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(french,         
                          u8"Français",   "fr",   ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(italian,       
                           u8"Italiano",   "it",   ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(japanese,       
                          u8"日本語",        "ja",   u8"\u3000"  ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(korean,         
                          u8"한국어",        "ko",   ascii_space ),<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;       LANG(spanish,       
                           u8"Español",    "es",   ascii_space )<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; ```<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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?<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; My general suggestion is
                that the specification of appropriate strings in<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a class="moz-txt-link-freetext" href="bitcoin:bips/bip-0039/">bitcoin:bips/bip-0039/</a><a
                  href="http://bip-0039-wordlists.md" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">bip-<wbr>0039-wordlists.md</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;  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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; 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).<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;
                ______________________________<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; _________________<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a
                  href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt; ______________________________<br>
                &gt;&gt;&gt;&gt;&gt;&gt; _________________<br>
                &gt;&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; <a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt; <a
                  href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt; &lt;signature.asc&gt;<br>
                &gt;&gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; ______________________________<br>
                &gt;&gt;&gt;&gt;&gt; _________________<br>
                &gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
                &gt;&gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;&gt; <a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                &gt;&gt;&gt;&gt;&gt; <a
                  href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
                &gt;&gt;&gt;&gt; --<br>
                &gt;&gt;&gt;&gt; Bitcoin transactions made simple:<br>
                &gt;&gt;&gt;&gt; <a
                  href="https://github.com/Ayms/bitcoin-transactions"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Zcash wallets made simple:<br>
                &gt;&gt;&gt;&gt; <a
                  href="https://github.com/Ayms/zcash-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/zcash-<wbr>wallets</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Bitcoin wallets made simple:<br>
                &gt;&gt;&gt;&gt; <a
                  href="https://github.com/Ayms/bitcoin-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-wallets</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Get the torrent dynamic blocklist:<br>
                &gt;&gt;&gt;&gt; <a
                  href="http://peersm.com/getblocklist" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">http://peersm.com/getblocklist</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Check the 10 M passwords list:<br>
                &gt;&gt;&gt;&gt; <a href="http://peersm.com/findmyass"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://peersm.com/findmyass</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Anti-spies and private torrents,
                dynamic blocklist:<br>
                &gt;&gt;&gt;&gt; <a href="http://torrent-live.org"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://torrent-live.org</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Peersm :<br>
                &gt;&gt;&gt;&gt; <a href="http://www.peersm.com"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.peersm.com</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; torrent-live:<br>
                &gt;&gt;&gt;&gt; <a
                  href="https://github.com/Ayms/torrent-live"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>torrent-live</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; node-Tor :<br>
                &gt;&gt;&gt;&gt; <a
                  href="https://www.github.com/Ayms/node-Tor"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms/<wbr>node-Tor</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; GitHub :<br>
                &gt;&gt;&gt;&gt; <a href="https://www.github.com/Ayms"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms</a><br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt; --<br>
                &gt;&gt;&gt; Bitcoin transactions made simple:<br>
                &gt;&gt;&gt; <a
                  href="https://github.com/Ayms/bitcoin-transactions"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Zcash wallets made simple:<br>
                &gt;&gt;&gt; <a
                  href="https://github.com/Ayms/zcash-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/zcash-<wbr>wallets</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Bitcoin wallets made simple:<br>
                &gt;&gt;&gt; <a
                  href="https://github.com/Ayms/bitcoin-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-wallets</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Get the torrent dynamic blocklist:<br>
                &gt;&gt;&gt; <a href="http://peersm.com/getblocklist"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://peersm.com/getblocklist</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Check the 10 M passwords list:<br>
                &gt;&gt;&gt; <a href="http://peersm.com/findmyass"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://peersm.com/findmyass</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Anti-spies and private torrents, dynamic
                blocklist:<br>
                &gt;&gt;&gt; <a href="http://torrent-live.org"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://torrent-live.org</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Peersm :<br>
                &gt;&gt;&gt; <a href="http://www.peersm.com"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.peersm.com</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; torrent-live:<br>
                &gt;&gt;&gt; <a
                  href="https://github.com/Ayms/torrent-live"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>torrent-live</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; node-Tor :<br>
                &gt;&gt;&gt; <a
                  href="https://www.github.com/Ayms/node-Tor"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms/<wbr>node-Tor</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; GitHub :<br>
                &gt;&gt;&gt; <a href="https://www.github.com/Ayms"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms</a><br>
                &gt;&gt;&gt;<br>
                <br>
                --<br>
                Bitcoin transactions made simple: <a
                  href="https://github.com/Ayms/bitcoin-transactions"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-transactions</a><br>
                Zcash wallets made simple: <a
                  href="https://github.com/Ayms/zcash-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/zcash-<wbr>wallets</a><br>
                Bitcoin wallets made simple: <a
                  href="https://github.com/Ayms/bitcoin-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>bitcoin-wallets</a><br>
                Get the torrent dynamic blocklist: <a
                  href="http://peersm.com/getblocklist" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">http://peersm.com/getblocklist</a><br>
                Check the 10 M passwords list: <a
                  href="http://peersm.com/findmyass" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">http://peersm.com/findmyass</a><br>
                Anti-spies and private torrents, dynamic blocklist: <a
                  href="http://torrent-live.org" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">http://torrent-live.org</a><br>
                Peersm : <a href="http://www.peersm.com"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.peersm.com</a><br>
                torrent-live: <a
                  href="https://github.com/Ayms/torrent-live%0Anode-Tor"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/<wbr>torrent-live<br>
                  node-Tor</a> : <a
                  href="https://www.github.com/Ayms/node-Tor"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms/<wbr>node-Tor</a><br>
                GitHub : <a href="https://www.github.com/Ayms"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://www.github.com/Ayms</a><br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
  </body>
</html>

--------------F9B669A59FD500FCB6DFD099--