path: root/63/8c9a9e87fc1847276372b87053c5c07b07c802

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 4E4D7BC5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Jan 2018 19:46:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com
	[209.85.128.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDDDA576
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Jan 2018 19:46:46 +0000 (UTC)
Received: by mail-wr0-f172.google.com with SMTP id f8so7143361wre.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Jan 2018 11:46:46 -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=5vXpYVXqPHMSBCZDga6405eeDupBiPcVm72YL1tTRAc=;
	b=URon6m7a0+60N2PawDsMSpT6xA/4o5LtDmhyIhba5vqvb4tJU5Ih24prD3qoI4mHb/
	3nHKOAx2ssSQB+ZKfHBNgS9LNxsSYPL375RVJjEJ5gKUtgEmYzWUwSUtpmx5bxH2FPyx
	1/d48O9nh7L+cabzpnjbxUT2TFshotDqr9FnRk66haQmgVPafLKzFHEkE1gMddjAoPTd
	+sK/mtlxha6LGXPpj5oe/mOOhJ+wWdRXO2ZtPbIfKVN/zgymHvTTQWJU94Jx81R7IK5x
	gKV29oWbuZ5YFxT+h0maI9RMTCoPZmeqCT+mblH/QX9uaSI1cqAc4xifuZCPbfW/HuuV
	E37A==
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=5vXpYVXqPHMSBCZDga6405eeDupBiPcVm72YL1tTRAc=;
	b=IgvGM/xdZcBpRmJE4fzXtPxBH+vAWKI95Cl/J8//qJ8xXxSevXRzKFi15knUReZyAo
	shV9w5yVcMjT0ClCz46idI1kOyvleb2sSzwk7SsSXzgh+i6PLxltSPpadgW4HMepcM66
	J8N9ZaJk7YpBKYGvY0WMlrBJMW3mD8SAcyNQ9qCCF4JE9rt3VzqE020WS5CZRnZq8mrF
	9N3kuMw5XcUGXF0ZHkhmORPjDzriLpPyVqF8w8/sPdlDHwuMdv+5fZ9zWcAyx9qvSU/4
	z/6CazMC+aXxRxUuPMHi2gjJk+b2N7A87rZg7muGjkeHDqv8d1boYMjas3FhDXOs9ydx
	O1MA==
X-Gm-Message-State: AKGB3mIL+7ZmFTXWq6u+m29/pyY0FCv2djbYRxqrVyJbFzUvI+a8iCBm
	B5+sCX4VSTWixtWyD+DZC7iJMA==
X-Google-Smtp-Source: ACJfBotyve89q0aFKJQNspDiOGJ484T5BMubbQtd1y4w+/+BepO9m+TequJY3ZCWmR1k4+fulgoK4w==
X-Received: by 10.223.199.145 with SMTP id l17mr6230015wrg.152.1515268005008; 
	Sat, 06 Jan 2018 11:46:45 -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
	j77sm16358327wmf.36.2018.01.06.11.46.42
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 06 Jan 2018 11:46:44 -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>
	<122d7820-3968-0c53-0156-23bf94a54ce2@gmail.com>
	<CALPhJaw8_wpPCRj58JcZqLnEvOtLoo=U_VBYRLSKTCeN7TFB6A@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <44d2accb-b0c6-069b-f8ac-421977ea792d@gmail.com>
Date: Sat, 6 Jan 2018 20:46:43 +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: <CALPhJaw8_wpPCRj58JcZqLnEvOtLoo=U_VBYRLSKTCeN7TFB6A@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------FA0EBE76F92A984D20C31EEA"
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:12:04 +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 19:46:50 -0000

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

Calm down now and stop your "do you want a" or "link" stupid comments,
whether you are really willing to propose some improvements, whether you
are just posting for nothing

BIP39:

"The length of the derived key is 512 bits (= 64 bytes).

This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods."

So the derived key is the seed? (derived key... this seed, really?
"similar methods",funny) That's not clear, then why everybody is using
xpriv which corresponds to the first step of the derivation (ie the
derived key)? And why BIP39 does not follow BIP32 recommendation (32B seed)?

Anyway, I don't really care about this stuff in fact, the only
interesting thing in this discussion beside arguing around unclear specs
misleading many people would be if you can convince that BIP39 & co are
really usefull for people (and easier than writing a seed): what
feedback do you have, don't you see how it's a pain in the xss for
everybody?

And if the answer is positive how can you can make it easier for people
(I am amazed too that people know about BIPXYZ, they should not),
probably this discussion will bore people and get moderated, but as
mentioned below, even maybe off topic, the subject is wider

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


--------------FA0EBE76F92A984D20C31EEA
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>Calm down now and stop your "do you want a" or "link" stupid
      comments, whether you are really willing to propose some
      improvements, whether you are just posting for nothing<br>
    </p>
    <p>BIP39: <br>
    </p>
    "The length of the derived key is 512 bits (= 64 bytes).
    <p>This seed can be later used to generate deterministic wallets
      using BIP-0032 or
      similar methods."</p>
    <p>So the derived key is the seed? (derived key... this seed,
      really? "similar methods",funny) That's not clear, then why
      everybody is using xpriv which corresponds to the first step of
      the derivation (ie the derived key)? And why BIP39 does not follow
      BIP32 recommendation (32B seed)?<br>
    </p>
    <p>Anyway, I don't really care about this stuff in fact, the only
      interesting thing in this discussion beside arguing around unclear
      specs misleading many people would be if you can convince that
      BIP39 &amp; co are really usefull for people (and easier than
      writing a seed): what feedback do you have, don't you see how it's
      a pain in the xss for everybody?</p>
    <p>And if the answer is positive how can you can make it easier for
      people (I am amazed too that people know about BIPXYZ, they should
      not), probably this discussion will bore people and get moderated,
      but as mentioned below, even maybe off topic, the subject is wider<br>
    </p>
    <div class="moz-cite-prefix">Le 06/01/2018 à 19:28, Alan Evans a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CALPhJaw8_wpPCRj58JcZqLnEvOtLoo=U_VBYRLSKTCeN7TFB6A@mail.gmail.com">
      <div dir="ltr">
        <div>&gt; <span style="font-size:12.8px">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</span></div>
        <div><span style="font-size:12.8px"><br>
          </span></div>
        <div>And yet you still fail to read the BIP, do you want a
          link? <a
            href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki"
            moz-do-not-send="true">https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki</a>
          I repeat it says:</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">between 128 and 512 bits</span><br>
        </div>
        <div><br>
        </div>
        <div>So, that's between 16 and 64 bytes, the advisory of 256 is
          clearly a minimum.</div>
        <div><br>
        </div>
        &gt; <span style="font-size:12.8px">That's another thing I
          completely dislike with BIP39, it ends up with xpriv, not the
          32B seed</span>
        <div><span style="font-size:12.8px"><br>
          </span></div>
        <div><span style="font-size:12.8px">Please also read BIP0039 <a
href="https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki"
              moz-do-not-send="true">https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki</a>,
            it generates </span><b style="font-size:12.8px">a BIP32
            seed only</b><span style="font-size:12.8px">, no </span>xpriv,<span
            style="font-size:12.8px"> that's completely false, then you
            use BIP0032 as normal with the seed. Because BIP0039
            produces a seed, your whole argument goes out of the window,
            you can write the seed if that's what you want to do, and
            throw away the mnemonic.</span></div>
        <div><br>
        </div>
        <div><span style="font-size:12.8px"><br>
          </span></div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sat, Jan 6, 2018 at 1:40 PM, 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">
            <div 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"
                  moz-do-not-send="true">https://github.com/Ayms/bitcoi<wbr>n-wallets</a>
                and even <a
                  href="https://github.com/Ayms/zcash-wallets"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/Ayms/zcash-<wbr>wallets
                  (not official but https://github.com/zcash/zips/<wbr>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="m_-250650141649817928moz-txt-link-freetext"
href="https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887"
                target="_blank" moz-do-not-send="true">https://bitcointalk.org/index.<wbr>php?topic=2550529.msg26133887#<wbr>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)
              <div>
                <div class="h5"><br>
                  <br>
                  <div class="m_-250650141649817928moz-cite-prefix">Le
                    06/01/2018 à 16:00, Alan Evans a écrit :<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div>You're mistaken. BIP32 does not require a
                        particular length. It recommends:
                        <div><br>
                        </div>
                        <div>
                          <ul>
                            <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>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="m_-250650141649817928HOEnZb">
                            <div class="m_-250650141649817928h5"><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"
                                target="_blank" 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"
                                target="_blank" 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"
                                target="_blank" 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/bitcoi<wbr>n-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"
                                target="_blank" 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"
                                target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfounda<wbr>tion.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/satoshilabs<wbr>/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"
                                target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfounda<wbr>tion.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/ea<wbr>syseed/blob/1a6e48bbdac9366d9d<wbr>5d1912dc062dfc3f0db2c6/<wbr>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="m_-250650141649817928moz-txt-link-freetext"
                                moz-do-not-send="true">bitcoin:bips/bip-0039/</a><a
                                href="http://bip-0039-wordlists.md"
                                rel="noreferrer" target="_blank"
                                moz-do-not-send="true">bip-0039<wbr>-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>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                    </div>
                  </blockquote>
                </div>
              </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>

--------------FA0EBE76F92A984D20C31EEA--