path: root/30/87828daa0521aec0d0c802b2d711d8de0db925

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <neillm@thecodefactory.org>) id 1YW24Q-0004SS-3l
	for Bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 12:18:34 +0000
Received-SPF: neutral (sog-mx-4.v43.ch3.sourceforge.com: 69.89.25.95 is
	neither permitted nor denied by domain of thecodefactory.org)
	client-ip=69.89.25.95; envelope-from=neillm@thecodefactory.org;
	helo=gproxy1-pub.mail.unifiedlayer.com; 
Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95])
	by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1YW24N-000291-Ma for Bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 12:18:34 +0000
Received: (qmail 25949 invoked by uid 0); 12 Mar 2015 11:51:46 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83)
	by gproxy1.mail.unifiedlayer.com with SMTP; 12 Mar 2015 11:51:46 -0000
Received: from box912.bluehost.com ([69.195.124.112]) by cmgw2 with 
	id 2brf1q00Q2Rd94501briKn; Thu, 12 Mar 2015 05:51:44 -0600
X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0
	a=6cBlaLCPswQtDQaCCnuzmw==:117 a=6cBlaLCPswQtDQaCCnuzmw==:17
	a=cNaOj0WVAAAA:8
	a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=8nJEP1OIZ-IA:10 a=77LCduB5AAAA:8
	a=MzLE66cuAAAA:8 a=qIbWpOXLPo4A:10 a=tP8ADxIfDBIA:10 a=emO1SXQWCLwA:10
	a=FP58Ms26AAAA:8 a=flBtlYYaQesZEmyrm3EA:9 a=0hrCi40nHQIUwJb9:21
	a=HbPI-4wo4t8Ki711:21 a=wPNLvfGTeEIA:10
Received: from [65.49.52.204] (port=57325 helo=localhost)
	by box912.bluehost.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128)
	(Exim 4.82) (envelope-from <neillm@thecodefactory.org>)
	id 1YW1eP-0001au-7u; Thu, 12 Mar 2015 05:51:41 -0600
Date: Thu, 12 Mar 2015 06:51:37 -0500
From: Neill Miller <neillm@thecodefactory.org>
To: Thy Shizzle <thashiznets@yahoo.com.au>
Message-ID: <20150312115137.GN4541@boiler.chaos.net>
References: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Identified-User: {2671:box912.bluehost.com:thecodef:thecodefactory.org}
	{sentby:smtp auth 65.49.52.204 authed with
	neillm+thecodefactory.org}
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [69.89.25.95 listed in list.dnswl.org]
	0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YW24N-000291-Ma
Cc: "Bitcoin-development@lists.sourceforge.net"
	<Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 12:18:34 -0000


Ok, I see your point here, and I was referring to rebuilding from
entropy -- which as you noted is not a real world usage.  It is a
useful implementation test though and at the very least the existing
test vectors would need to be regenerated with each word list change.

I recently added BIP39 to libbitcoin and our implementation would fail
with an arbitrarily new word list because we validate the user
provided word list before converting it to a seed (i.e. we check that
the encoded entropy/checksum line up and warn the user if that's not
the case to distinguish a rubbish word list from a BIP39 mnemonic --
as referenced in the BIP).  You're correct that we could use rubbish
words, but at the moment it's not allowed there.  By removing that
validating 'restriction', I agree with you that word lists have no
need to be fixed.  But realistically, we still don't allow completely
arbitrary words to be used because I don't see the word lists changing
too often, nor implementations storing word lists of all words and
languages.

Thanks for clarifying,
-Neill.

On Thu, Mar 12, 2015 at 04:21:59AM +0000, Thy Shizzle wrote:
> "I agree that it's true that a static wordlist is
>  required once people have started using BIP39 for anything real and
>  changing the word lists will invalidate any existing mnemonics"
> ^ This is incorrect I think Neill, the reason is that the only thing that=
 happens when you change the wordlist is that entropy points to different w=
ords. But remember, entropy is disposed. Yes in my code I allow for the kee=
ping of entropy etc, it also lets me "hot swap" between different language =
wordlists etc but in real world implementation the entropy is forgotten and=
 not stored. So changing the wordlist merely allows new mnemonic phrases to=
 be generated but it has a nil impact on previously generated mnemonics UNL=
ESS you are trying to rebuild from entropy but you wouldn't do that. You wo=
uld be rebuilding from the Mnemonic in real world scenario. You really can =
have a word list of total rubbish in BIP39 as long as it is 2048 words long=
 that is all! If you input the mnemonic made out of rubbish words so for e.=
g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwe=
trtr" and no matter what BIP39 implementation you put it in, it will always=
 generate the same seed bytes thus allowing for complete and universal seed=
 derivation without any reliance on word list. The word list is merely to g=
enerate a mnemonic, after that it has no role in seed generation so you can=
 change it at anytime and it will never effect future mnemonics.
>=20
> On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> > That's disappointing the Electrum 2.0 doesn't use BIP39.
>=20
> Agreed, but I don't know the full background on this.
>=20
> > Changing the wordlist in the future has ZERO effect on derived seed, wh=
atever mnemonic you provide will always generate the same seed, BIP39 is no=
t mapping the words back to numbers etc to derive seed.
>=20
> That's true for generating new mnemonics (i.e. same entropy can
> generate any combinations of words), but not for converting a mnemonic
> to a seed (i.e. a specific wordlist/passphrase should always generate
> the same seed).=A0 I agree that it's true that a static wordlist is
> required once people have started using BIP39 for anything real and
> changing the word lists will invalidate any existing mnemonics (unless
> your 'new' wordlist simply substitutes one word for another and the
> index mapping is made public ... which means it's not really an
> arbitrary word list).
>=20
> > Version is something that can be dealt with after the fact, hopefully s=
tandardised (curious why didn't you work with the BIP39 to insert version i=
nstead of do something different to BIP39?)
> > So most of what you are suggesting as problems are not.
>=20
> I don't see how this can work given the BIP39 spec as it is today
> (there's simply no room for a version in the bits).=A0 I do think
> versioning would be nice, but as of now, I'm in the camp that thinks
> complete wallet interoperability is a bit of a myth -- so long as you
> can fundamentally move into/out of wallets at will.
>=20
> -Neill.
>=20
> > As for the common words between languages, I have discussed this with t=
he provider of the Chinese wordlists as they shared some words between simp=
lified and traditional, but I found it easy to look for a word in the mnemo=
nic that is unique to that language/wordlist and so straight away you can d=
etermine the language, remembering you get minimum 12 goes at doing that :)
> > Also then I asked myself, do we really care about detecting the languag=
e? Probably not because we don't need to use the wordlist ever again after =
creation, we literally accept the mnemonic, normalise it then hash it into =
a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it wo=
uld take almost no effort to put it in and I think you should do that :) I =
don't have any interest in BIP39 other than it being a standard. I think TR=
EZOR may have an interest in it?
> > Thomas V:
> > "Thanks Mike, and sorry to answer a bit late; it has been a busy couple
> > of weeks.
> >=20
> > You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> > versa. It is indeed unfortunate. However, I believe BIP39 should not be
> > followed, because it reproduces two mistakes I did when I designed the
> > older Electrum seed system. Let me explain.
> >=20
> > The first problem I have with BIP39 is that the seed phrase does not
> > include a version number.
> >=20
> > Wallet development is still in an exploratory phase, and we should
> > expect even more innovation in this domain. In this context, it is
> > unwise to make decisions that prevent future innovation.
> >=20
> > However, when we give a seed phrase to users, we have a moral obligation
> > to keep supporting this seed phrase in future versions. We cannot simply
> > announce to Electrum users that their old seed phrase is not supported
> > anymore, because we created a new version of the software that uses a
> > different derivation. This could lead to financial losses for users who
> > are unaware of these technicalities. Well, at least, that is how I feel
> > about it.
> >=20
> > BIP39 and Electrum v2 have a very different ways of handling future
> > innovation. Electrum v2 seed phrases include an explicit version number,
> > that indicates how the wallet addresses should be derived. In contrast,
> > BIP39 seed phrases do not include a version number at all. BIP39 is
> > meant to be combined with BIP43, which stipulates that the wallet
> > structure should depend on the BIP32 derivation path used for the wallet
> > (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> > innovation in BIP43 is allowed only within the framework of BIP32. In
> > addition, having to explore the branches of the BIP32 tree in order to
> > determine the type of wallet attached to a seed might be somewhat
> > inefficient.
> >=20
> > The second problem I see with BIP39 is that it requires a fixed
> > wordlist. Of course, this forbids innovation in the wordlist itself, but
> > that's not the main problem. When you write a new standard, it is
> > important to keep this standard minimal, given the goal you want to
> > achieve. I believe BIP39 could (and should) have been written without
> > including the wordlist in the standard.
> >=20
> > There are two ways to derive a master key from a mnemonic phrase:
> > =A01. A bidirectional mapping between words and numbers, as in old
> > Electrum versions. Pros: bidirectional means that you can do Shamir
> > secret sharing of your seed. Cons: It requires a fixed wordlist.
> > =A02. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is =
not
> > required. Cons: the mapping isn't bidirectional.
> >=20
> > Electrum v1 uses (1). Electrum v2 uses (2).
> >=20
> > Early versions of BIP39 used (1), and later they switched to (2).
> > However, BIP39 uses (2) only in order to derive the wallet keys, not for
> > its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> > wordlist. This is just plainly inconsistent. As a result, you have
> > neither wordlist flexibility, nor Shamir secret sharing.
> >=20
> > Having a fixed wordlist is very unfortunate. First, it means that BIP39
> > will probably never leave the 'draft' stage, until all languages of the
> > world have been added. Second, once you add a wordlist for a new
> > language, you cannot change it anymore, because it will break existing
> > seed phrases; therefore you have to be extremely careful in the way you
> > design these wordlists. Third, languages often have words in common.
> > When you add a new language to the list, you should not use words
> > already used by existing wordlists, in order to ensure that the language
> > can be detected. It leads to a first come first served situation, that
> > might not be sustainable in the future.
> >=20
> > In order to support the old Electrum v1 seeds, all future versions of
> > Electrum will have to include the old wordlist. In addition, when
> > generating new seed phrases, Electrum now has to avoid collisions with
> > old seed phrases, because the old ones did not have a version number.
> > This is painful enough, I will not repeat the same errors twice.
> >=20
> > Electrum v2 derives both its private keys and its checksum/version
> > number using a hash of the seed phrase. This means that wordlists can be
> > added and modified in the future, without breaking existing seed
> > phrases. It also means that it will be very easy for other wallets to
> > support Electrum seedphrases: it requires about 20 lines of code, and no
> > wordlist is required."
> >=20
> >=20
> > Thomas
> >=20
> >=20
> > Le 02/03/2015 16:37, Mike Hearn a =E9crit :
> > > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > >=20
> > >=20
> > >> * New seed derivation method (not compatible with BIP39).
> > >=20
> > >=20
> > > Does this mean a "12 words" wallet created by Electrum won't work if
> > > imported into some other wallet that supports BIP39? Vice versa? This=
 seems
> > > unfortunate. I guess if seeds are being represented with 12 words
> > > consistently, people will expect them to work everywhere.
> > >=20
> >=20
> > -----------------------------------------------------------------------=
-------
> > Dive into the World of Parallel Programming The Go Parallel Website, sp=
onsored
> > by Intel and developed in partnership with Slashdot Media, is your hub =
for all
> > things parallel software development, from weekly thought leadership bl=
ogs to
> > news, videos, case studies, tutorials and more. Take a look and join th=
e=20
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > Bitcoin-development --
> > | =A0 |
> > | =A0 | =A0 | =A0 | =A0 | =A0 |
> > | Bitcoin-development --To see the collection of prior postings to the =
list, visit the Bitcoin-development Archives. |
> > |=A0 |
> > | View on lists.sourceforge.net | Preview by Yahoo |
> > |=A0 |
> > | =A0 |
> >=20
> >=A0 =A0
> >=20
> >=A0=20
> >=A0=A0=A0=20
>=20
> > -----------------------------------------------------------------------=
-------
> > Dive into the World of Parallel Programming The Go Parallel Website, sp=
onsored
> > by Intel and developed in partnership with Slashdot Media, is your hub =
for all
> > things parallel software development, from weekly thought leadership bl=
ogs to
> > news, videos, case studies, tutorials and more. Take a look and join th=
e=20
> > conversation now. http://goparallel.sourceforge.net/
>=20
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development