From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YW699-0008Mv-78 for Bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 16:39:43 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of niftybox.net designates 95.142.167.147 as permitted sender) client-ip=95.142.167.147; envelope-from=c1.sf-bitcoin@niftybox.net; helo=i3.hyper.to; Received: from i3.hyper.to ([95.142.167.147]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YW696-0000W6-R6 for Bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 16:39:43 +0000 Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id 6D273E0153; Thu, 12 Mar 2015 17:39:34 +0100 (CET) Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0BqHRHUzdUOx; Thu, 12 Mar 2015 17:39:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id D8B13E0166; Thu, 12 Mar 2015 17:39:32 +0100 (CET) X-Virus-Scanned: amavisd-new at i3.hyper.to Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fvCKfjhT9THW; Thu, 12 Mar 2015 17:39:32 +0100 (CET) Received: from [10.1.10.188] (142-254-47-143.dsl.dynamic.sonic.net [142.254.47.143]) by i3.hyper.to (Postfix) with ESMTPSA id C26E0E0153; Thu, 12 Mar 2015 17:39:31 +0100 (CET) Message-ID: <5501C141.2080501@niftybox.net> Date: Thu, 12 Mar 2015 09:39:29 -0700 From: devrandom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Neill Miller , Thy Shizzle References: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com> <20150312115137.GN4541@boiler.chaos.net> In-Reply-To: <20150312115137.GN4541@boiler.chaos.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YW696-0000W6-R6 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 16:39:43 -0000 On 2015-03-12 04:51 AM, Neill Miller wrote: >=20 > 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. >=20 > 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. A good way to go about this from a UX point of view is warn the user that their "phrase is non-standard", but allow them to insist. >=20 > Thanks for clarifying, > -Neill. >=20 > 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 t= hat happens when you change the wordlist is that entropy points to differ= ent words. But remember, entropy is disposed. Yes in my code I allow for = the keeping of entropy etc, it also lets me "hot swap" between different = language wordlists etc but in real world implementation the entropy is fo= rgotten and not stored. So changing the wordlist merely allows new mnemon= ic phrases to be generated but it has a nil impact on previously generate= d mnemonics UNLESS you are trying to rebuild from entropy but you wouldn'= t do that. You would be rebuilding from the Mnemonic in real world scenar= io. 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 sdasd= s uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation yo= u put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without a= ny reliance on word list. The word list is merely to generate a mnemonic,= after that it has no role in seed generation so you can change it at any= time and it will never effect future mnemonics. >> >> On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote: >>> That's disappointing the Electrum 2.0 doesn't use BIP39. >> >> Agreed, but I don't know the full background on this. >> >>> Changing the wordlist in the future has ZERO effect on derived seed, = whatever mnemonic you provide will always generate the same seed, BIP39 i= s not mapping the words back to numbers etc to derive seed. >> >> 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). 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). >> >>> Version is something that can be dealt with after the fact, hopefully= standardised (curious why didn't you work with the BIP39 to insert versi= on instead of do something different to BIP39?) >>> So most of what you are suggesting as problems are not. >> >> 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). 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. >> >> -Neill. >> >>> As for the common words between languages, I have discussed this with= the provider of the Chinese wordlists as they shared some words between = simplified and traditional, but I found it easy to look for a word in the= mnemonic that is unique to that language/wordlist and so straight away y= ou can determine the language, remembering you get minimum 12 goes at doi= ng that :) >>> Also then I asked myself, do we really care about detecting the langu= age? Probably not because we don't need to use the wordlist ever again af= ter 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 BIP3= 9, it would 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 TREZOR may have an interest in it? >>> Thomas V: >>> "Thanks Mike, and sorry to answer a bit late; it has been a busy coup= le >>> of weeks. >>> >>> You are correct, a BIP39 seed phrase will not work in Electrum, and v= ice >>> versa. It is indeed unfortunate. However, I believe BIP39 should not = be >>> followed, because it reproduces two mistakes I did when I designed th= e >>> older Electrum seed system. Let me explain. >>> >>> The first problem I have with BIP39 is that the seed phrase does not >>> include a version number. >>> >>> 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. >>> >>> However, when we give a seed phrase to users, we have a moral obligat= ion >>> to keep supporting this seed phrase in future versions. We cannot sim= ply >>> announce to Electrum users that their old seed phrase is not supporte= d >>> anymore, because we created a new version of the software that uses a >>> different derivation. This could lead to financial losses for users w= ho >>> are unaware of these technicalities. Well, at least, that is how I fe= el >>> about it. >>> >>> BIP39 and Electrum v2 have a very different ways of handling future >>> innovation. Electrum v2 seed phrases include an explicit version numb= er, >>> that indicates how the wallet addresses should be derived. In contras= t, >>> 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 wal= let >>> (although BIP43 is not followed by all BIP39 compatible wallets). Thu= s, >>> innovation in BIP43 is allowed only within the framework of BIP32. In >>> addition, having to explore the branches of the BIP32 tree in order t= o >>> determine the type of wallet attached to a seed might be somewhat >>> inefficient. >>> >>> 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. >>> >>> There are two ways to derive a master key from a mnemonic phrase: >>> 1. 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. >>> 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is = not >>> required. Cons: the mapping isn't bidirectional. >>> >>> Electrum v1 uses (1). Electrum v2 uses (2). >>> >>> 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 fix= ed >>> wordlist. This is just plainly inconsistent. As a result, you have >>> neither wordlist flexibility, nor Shamir secret sharing. >>> >>> Having a fixed wordlist is very unfortunate. First, it means that BIP= 39 >>> will probably never leave the 'draft' stage, until all languages of t= he >>> world have been added. Second, once you add a wordlist for a new >>> language, you cannot change it anymore, because it will break existin= g >>> seed phrases; therefore you have to be extremely careful in the way y= ou >>> 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 langu= age >>> can be detected. It leads to a first come first served situation, tha= t >>> might not be sustainable in the future. >>> >>> 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 wit= h >>> 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. >>> >>> 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." >>> >>> >>> Thomas >>> >>> >>> Le 02/03/2015 16:37, Mike Hearn a =E9crit : >>>> Congrats Thomas! Glad to see Electrum 2 finally launch. >>>> >>>> >>>>> * New seed derivation method (not compatible with BIP39). >>>> >>>> >>>> Does this mean a "12 words" wallet created by Electrum won't work if >>>> imported into some other wallet that supports BIP39? Vice versa? Thi= s seems >>>> unfortunate. I guess if seeds are being represented with 12 words >>>> consistently, people will expect them to work everywhere. >>>> >>> >>> ---------------------------------------------------------------------= --------- >>> Dive into the World of Parallel Programming The Go Parallel Website, = sponsored >>> by Intel and developed in partnership with Slashdot Media, is your hu= b for all >>> things parallel software development, from weekly thought leadership = blogs to >>> news, videos, case studies, tutorials and more. Take a look and join = the=20 >>> conversation now. http://goparallel.sourceforge.net/ >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> Bitcoin-development -- >>> | | >>> | | | | | | >>> | Bitcoin-development --To see the collection of prior postings to th= e list, visit the Bitcoin-development Archives. | >>> | | >>> | View on lists.sourceforge.net | Preview by Yahoo | >>> | | >>> | | >>> >>> =20 >>> >>> =20 >>> =20 >> >>> ---------------------------------------------------------------------= --------- >>> Dive into the World of Parallel Programming The Go Parallel Website, = sponsored >>> by Intel and developed in partnership with Slashdot Media, is your hu= b for all >>> things parallel software development, from weekly thought leadership = blogs to >>> news, videos, case studies, tutorials and more. Take a look and join = the=20 >>> conversation now. http://goparallel.sourceforge.net/ >> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=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 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --=20 devrandom / Miron