From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ) id 1YW1eP-0001au-7u; Thu, 12 Mar 2015 05:51:41 -0600 Date: Thu, 12 Mar 2015 06:51:37 -0500 From: Neill Miller To: Thy Shizzle 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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