Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YW2hs-0004uj-EX for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 12:59:20 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of outlook.com designates 65.55.34.17 as permitted sender) client-ip=65.55.34.17; envelope-from=thyshizzle@outlook.com; helo=COL004-OMC1S7.hotmail.com; Received: from col004-omc1s7.hotmail.com ([65.55.34.17]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YW2hp-0000jF-D2 for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 12:59:20 +0000 Received: from COL130-W39 ([65.55.34.9]) by COL004-OMC1S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 05:59:11 -0700 X-TMN: [Sq1+Lm+uv+V+c+fcjxsllLROMSEWTjGeIHSzYK9RC6c=] X-Originating-Email: [thyshizzle@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_1192efe0-4738-4ad6-a708-b47acfd53f0b_" From: Thy Shizzle To: Neill Miller , "thomasv@electrum.org" Date: Thu, 12 Mar 2015 23:59:11 +1100 Importance: Normal In-Reply-To: <20150312115137.GN4541@boiler.chaos.net> References: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com>, <20150312115137.GN4541@boiler.chaos.net> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2015 12:59:11.0851 (UTC) FILETIME=[55EA53B0:01D05CC4] X-Spam-Score: 0.0 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (thyshizzle[at]outlook.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.17 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails -0.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YW2hp-0000jF-D2 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:59:20 -0000 --_1192efe0-4738-4ad6-a708-b47acfd53f0b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable @Neill=2C Indeed supplying entropy is necessary for testing etc=2C that's t= he main reason why I put this in my .NET implementation=2C the test vectors= require us to supply entropy and build the mnemonic from the supplied word= list and you are correct that changes to the word list will null and void t= he test vectors. Also it allows us to do fun things like swap between langu= ages so one entropy set can have many seeds based on many languages etc=2C = just novel little things like that. I'm not at all against a standard wordl= ist. The point I want to get across is that people seem to think that BIP39= is restricted by its word list but not at all. As long as you give a BIP39= implementation 12 words or more (in 3 word increments) it will always deri= ve the same seed bytes=2C independent of any word list and this is the most= important message to realise. @Thomas V if you must record a version=2C why don't you just put an integer= at the end of your mnemonic or something? I can't understand why you have = disregarded BIP39 when designing Electrum 2.0? 12 - 24 words plus a versio= n integer tacked on the end=2C tell the user to omit the version integer if= they want to import to multibit HD or whatever=2C job done! I really think you need to rethink the use of BIP39 with Electrum Thomas! I= f you want to maintain a version field and/or date independent of the BIP39= spec then do so because at least the seed can still be recreated from anyo= ne else utilising BIP39!!! Thy > Date: Thu=2C 12 Mar 2015 06:51:37 -0500 > From: neillm@thecodefactory.org > To: thashiznets@yahoo.com.au > CC: Bitcoin-development@lists.sourceforge.net > Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged >=20 >=20 > Ok=2C I see your point here=2C 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=2C but at the moment it's not allowed there. By removing that > validating 'restriction'=2C I agree with you that word lists have no > need to be fixed. But realistically=2C we still don't allow completely > arbitrary words to be used because I don't see the word lists changing > too often=2C nor implementations storing word lists of all words and > languages. >=20 > Thanks for clarifying=2C > -Neill. >=20 > On Thu=2C Mar 12=2C 2015 at 04:21:59AM +0000=2C 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=2C the reason is that the only thing = that happens when you change the wordlist is that entropy points to differe= nt words. But remember=2C entropy is disposed. Yes in my code I allow for t= he keeping of entropy etc=2C it also lets me "hot swap" between different l= anguage wordlists etc but in real world implementation the entropy is forgo= tten and not stored. So changing the wordlist merely allows new mnemonic ph= rases to be generated but it has a nil impact on previously generated mnemo= nics UNLESS you are trying to rebuild from entropy but you wouldn't do that= . You would be rebuilding from the Mnemonic in real world scenario. You rea= lly can have a word list of total rubbish in BIP39 as long as it is 2048 wo= rds long that is all! If you input the mnemonic made out of rubbish words s= o for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd t= yyty rwetrtr" and no matter what BIP39 implementation you put it in=2C it w= ill always generate the same seed bytes thus allowing for complete and univ= ersal seed derivation without any reliance on word list. The word list is m= erely to generate a mnemonic=2C after that it has no role in seed generatio= n so you can change it at anytime and it will never effect future mnemonics= . > >=20 > > On Thu=2C Mar 12=2C 2015 at 02:16:38AM +0000=2C Thy Shizzle wrote: > > > That's disappointing the Electrum 2.0 doesn't use BIP39. > >=20 > > Agreed=2C but I don't know the full background on this. > >=20 > > > Changing the wordlist in the future has ZERO effect on derived seed= =2C whatever mnemonic you provide will always generate the same seed=2C BIP= 39 is not 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)=2C but not for converting a mnemoni= c > > 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). > >=20 > > > Version is something that can be dealt with after the fact=2C hopeful= ly 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. > >=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). I do think > > versioning would be nice=2C but as of now=2C I'm in the camp that think= s > > 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=2C I have discussed this wi= th the provider of the Chinese wordlists as they shared some words between = simplified and traditional=2C but I found it easy to look for a word in the= mnemonic that is unique to that language/wordlist and so straight away you= can determine the language=2C remembering you get minimum 12 goes at doing= that :) > > > Also then I asked myself=2C do we really care about detecting the lan= guage? Probably not because we don't need to use the wordlist ever again af= ter creation=2C we literally accept the mnemonic=2C normalise it then hash = it into a seed. From what I'm reading=2C Electrum 2.0 really should have BI= P39=2C it would take almost no effort to put it in and I think you should d= o 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=2C and sorry to answer a bit late=3B it has been a busy = couple > > > of weeks. > > >=20 > > > You are correct=2C a BIP39 seed phrase will not work in Electrum=2C a= nd vice > > > versa. It is indeed unfortunate. However=2C I believe BIP39 should no= t be > > > followed=2C 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=2C and we should > > > expect even more innovation in this domain. In this context=2C it is > > > unwise to make decisions that prevent future innovation. > > >=20 > > > However=2C when we give a seed phrase to users=2C we have a moral obl= igation > > > 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=2C 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=2C at least=2C 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 numb= er=2C > > > that indicates how the wallet addresses should be derived. In contras= t=2C > > > BIP39 seed phrases do not include a version number at all. BIP39 is > > > meant to be combined with BIP43=2C 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=2C > > > innovation in BIP43 is allowed only within the framework of BIP32. In > > > addition=2C 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=2C this forbids innovation in the wordlist itself= =2C but > > > that's not the main problem. When you write a new standard=2C it is > > > important to keep this standard minimal=2C 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: > > > 1. A bidirectional mapping between words and numbers=2C 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. > > >=20 > > > Electrum v1 uses (1). Electrum v2 uses (2). > > >=20 > > > Early versions of BIP39 used (1)=2C and later they switched to (2). > > > However=2C BIP39 uses (2) only in order to derive the wallet keys=2C = not for > > > its checksum. The BIP39 checksum uses (1)=2C and it does requires a f= ixed > > > wordlist. This is just plainly inconsistent. As a result=2C you have > > > neither wordlist flexibility=2C nor Shamir secret sharing. > > >=20 > > > Having a fixed wordlist is very unfortunate. First=2C it means that B= IP39 > > > will probably never leave the 'draft' stage=2C until all languages of= the > > > world have been added. Second=2C once you add a wordlist for a new > > > language=2C you cannot change it anymore=2C because it will break exi= sting > > > seed phrases=3B therefore you have to be extremely careful in the way= you > > > design these wordlists. Third=2C languages often have words in common= . > > > When you add a new language to the list=2C you should not use words > > > already used by existing wordlists=2C in order to ensure that the lan= guage > > > can be detected. It leads to a first come first served situation=2C t= hat > > > might not be sustainable in the future. > > >=20 > > > In order to support the old Electrum v1 seeds=2C all future versions = of > > > Electrum will have to include the old wordlist. In addition=2C when > > > generating new seed phrases=2C Electrum now has to avoid collisions w= ith > > > old seed phrases=2C because the old ones did not have a version numbe= r. > > > This is painful enough=2C 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=2C 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=2C a= nd no > > > wordlist is required." > > >=20 > > >=20 > > > Thomas > > >=20 > > >=20 > > > Le 02/03/2015 16:37=2C 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 i= f > > > > imported into some other wallet that supports BIP39? Vice versa? Th= is seems > > > > unfortunate. I guess if seeds are being represented with 12 words > > > > consistently=2C people will expect them to work everywhere. > > > >=20 > > >=20 > > > ---------------------------------------------------------------------= --------- > > > Dive into the World of Parallel Programming The Go Parallel Website= =2C sponsored > > > by Intel and developed in partnership with Slashdot Media=2C is your = hub for all > > > things parallel software development=2C from weekly thought leadershi= p blogs to > > > news=2C videos=2C case studies=2C 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=2C visit the Bitcoin-development Archives. | > > > | | > > > | View on lists.sourceforge.net | Preview by Yahoo | > > > | | > > > | | > > >=20 > > > =20 > > >=20 > > > =20 > > > =20 > >=20 > > > ---------------------------------------------------------------------= --------- > > > Dive into the World of Parallel Programming The Go Parallel Website= =2C sponsored > > > by Intel and developed in partnership with Slashdot Media=2C is your = hub for all > > > things parallel software development=2C from weekly thought leadershi= p blogs to > > > news=2C videos=2C case studies=2C tutorials and more. Take a look and= join the=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 >=20 > -------------------------------------------------------------------------= ----- > Dive into the World of Parallel Programming The Go Parallel Website=2C sp= onsored > by Intel and developed in partnership with Slashdot Media=2C is your hub = for all > things parallel software development=2C from weekly thought leadership bl= ogs to > news=2C videos=2C case studies=2C tutorials and more. Take a look and joi= n 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 = --_1192efe0-4738-4ad6-a708-b47acfd53f0b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
@Neill=2C Indeed supplying entro= py is necessary for testing etc=2C that's the main reason why I put this in= my .NET implementation=2C the test vectors require us to supply entropy an= d build the mnemonic from the supplied wordlist and you are correct that ch= anges to the word list will null and void the test vectors. Also it allows = us to do fun things like swap between languages so one entropy set can have= many seeds based on many languages etc=2C just novel little things like th= at. I'm not at all against a standard wordlist. The point I want to get acr= oss is that people seem to think that BIP39 is restricted by its word list = but not at all. As long as you give a BIP39 implementation 12 words or more= (in 3 word increments) it will always derive the same seed bytes=2C indepe= ndent of any word list and this is the most important message to realise.
@Thomas V if you must record a version=2C why don't you just put an i= nteger at the end of your mnemonic or something? I can't understand why you= have disregarded BIP39 when designing Electrum 2.0? =3B 12 - 24 words = plus a version integer tacked on the end=2C tell the user to omit the versi= on integer if they want to import to multibit HD or whatever=2C job done!
I really think you need to rethink the use of BIP39 with Electrum Tho= mas! If you want to maintain a version field and/or date independent of the= BIP39 spec then do so because at least the seed can still be recreated fro= m anyone else utilising BIP39!!!

Thy

>=3B Date: Thu=2C= 12 Mar 2015 06:51:37 -0500
>=3B From: neillm@thecodefactory.org
&g= t=3B To: thashiznets@yahoo.com.au
>=3B CC: Bitcoin-development@lists.s= ourceforge.net
>=3B Subject: Re: [Bitcoin-development] Electrum 2.0 ha= s been tagged
>=3B
>=3B
>=3B Ok=2C I see your point here= =2C and I was referring to rebuilding from
>=3B entropy -- which as yo= u noted is not a real world usage. It is a
>=3B useful implementation= test though and at the very least the existing
>=3B test vectors woul= d need to be regenerated with each word list change.
>=3B
>=3B I= recently added BIP39 to libbitcoin and our implementation would fail
&g= t=3B with an arbitrarily new word list because we validate the user
>= =3B provided word list before converting it to a seed (i.e. we check that>=3B the encoded entropy/checksum line up and warn the user if that's n= ot
>=3B the case to distinguish a rubbish word list from a BIP39 mnemo= nic --
>=3B as referenced in the BIP). You're correct that we could u= se rubbish
>=3B words=2C but at the moment it's not allowed there. By= removing that
>=3B validating 'restriction'=2C I agree with you that = word lists have no
>=3B need to be fixed. But realistically=2C we sti= ll don't allow completely
>=3B arbitrary words to be used because I do= n't see the word lists changing
>=3B too often=2C nor implementations = storing word lists of all words and
>=3B languages.
>=3B
>= =3B Thanks for clarifying=2C
>=3B -Neill.
>=3B
>=3B On Thu= =2C Mar 12=2C 2015 at 04:21:59AM +0000=2C Thy Shizzle wrote:
>=3B >= =3B "I agree that it's true that a static wordlist is
>=3B >=3B req= uired once people have started using BIP39 for anything real and
>=3B = >=3B changing the word lists will invalidate any existing mnemonics"
= >=3B >=3B ^ This is incorrect I think Neill=2C the reason is that the o= nly thing that happens when you change the wordlist is that entropy points = to different words. But remember=2C entropy is disposed. Yes in my code I a= llow for the keeping of entropy etc=2C it also lets me "hot swap" between d= ifferent language wordlists etc but in real world implementation the entrop= y is forgotten and not stored. So changing the wordlist merely allows new m= nemonic phrases to be generated but it has a nil impact on previously gener= ated 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 scenari= o. 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 rubbi= sh words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyu= y sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it = in=2C it will always generate the same seed bytes thus allowing for complet= e and universal seed derivation without any reliance on word list. The word= list is merely to generate a mnemonic=2C after that it has no role in seed= generation so you can change it at anytime and it will never effect future= mnemonics.
>=3B >=3B
>=3B >=3B On Thu=2C Mar 12=2C 2015 at = 02:16:38AM +0000=2C Thy Shizzle wrote:
>=3B >=3B >=3B That's disap= pointing the Electrum 2.0 doesn't use BIP39.
>=3B >=3B
>=3B &g= t=3B Agreed=2C but I don't know the full background on this.
>=3B >= =3B
>=3B >=3B >=3B Changing the wordlist in the future has ZERO e= ffect on derived seed=2C whatever mnemonic you provide will always generate= the same seed=2C BIP39 is not mapping the words back to numbers etc to der= ive seed.
>=3B >=3B
>=3B >=3B That's true for generating new= mnemonics (i.e. same entropy can
>=3B >=3B generate any combination= s of words)=2C but not for converting a mnemonic
>=3B >=3B to a seed= (i.e. a specific wordlist/passphrase should always generate
>=3B >= =3B the same seed). =3B I agree that it's true that a static wordlist i= s
>=3B >=3B required once people have started using BIP39 for anythi= ng real and
>=3B >=3B changing the word lists will invalidate any ex= isting mnemonics (unless
>=3B >=3B your 'new' wordlist simply substi= tutes one word for another and the
>=3B >=3B index mapping is made p= ublic ... which means it's not really an
>=3B >=3B arbitrary word li= st).
>=3B >=3B
>=3B >=3B >=3B Version is something that ca= n be dealt with after the fact=2C hopefully standardised (curious why didn'= t you work with the BIP39 to insert version instead of do something differe= nt to BIP39?)
>=3B >=3B >=3B So most of what you are suggesting as= problems are not.
>=3B >=3B
>=3B >=3B I don't see how this = can work given the BIP39 spec as it is today
>=3B >=3B (there's simp= ly no room for a version in the bits). =3B I do think
>=3B >=3B = versioning would be nice=2C but as of now=2C I'm in the camp that thinks>=3B >=3B complete wallet interoperability is a bit of a myth -- so lo= ng as you
>=3B >=3B can fundamentally move into/out of wallets at wi= ll.
>=3B >=3B
>=3B >=3B -Neill.
>=3B >=3B
>=3B = >=3B >=3B As for the common words between languages=2C I have discussed= this with the provider of the Chinese wordlists as they shared some words = between simplified and traditional=2C but I found it easy to look for a wor= d in the mnemonic that is unique to that language/wordlist and so straight = away you can determine the language=2C remembering you get minimum 12 goes = at doing that :)
>=3B >=3B >=3B Also then I asked myself=2C do we = really care about detecting the language? Probably not because we don't nee= d to use the wordlist ever again after creation=2C we literally accept the = mnemonic=2C normalise it then hash it into a seed. From what I'm reading=2C= Electrum 2.0 really should have BIP39=2C it would take almost no effort to= put it in and I think you should do that :) I don't have any interest in B= IP39 other than it being a standard. I think TREZOR may have an interest in= it?
>=3B >=3B >=3B Thomas V:
>=3B >=3B >=3B "Thanks Mike= =2C and sorry to answer a bit late=3B it has been a busy couple
>=3B &= gt=3B >=3B of weeks.
>=3B >=3B >=3B
>=3B >=3B >=3B You= are correct=2C a BIP39 seed phrase will not work in Electrum=2C and vice>=3B >=3B >=3B versa. It is indeed unfortunate. However=2C I believ= e BIP39 should not be
>=3B >=3B >=3B followed=2C because it reprod= uces two mistakes I did when I designed the
>=3B >=3B >=3B older E= lectrum seed system. Let me explain.
>=3B >=3B >=3B
>=3B >= =3B >=3B The first problem I have with BIP39 is that the seed phrase does= not
>=3B >=3B >=3B include a version number.
>=3B >=3B >= =3B
>=3B >=3B >=3B Wallet development is still in an exploratory = phase=2C and we should
>=3B >=3B >=3B expect even more innovation = in this domain. In this context=2C it is
>=3B >=3B >=3B unwise to = make decisions that prevent future innovation.
>=3B >=3B >=3B
= >=3B >=3B >=3B However=2C when we give a seed phrase to users=2C we h= ave a moral obligation
>=3B >=3B >=3B to keep supporting this seed= phrase in future versions. We cannot simply
>=3B >=3B >=3B announ= ce to Electrum users that their old seed phrase is not supported
>=3B = >=3B >=3B anymore=2C because we created a new version of the software t= hat uses a
>=3B >=3B >=3B different derivation. This could lead to= financial losses for users who
>=3B >=3B >=3B are unaware of thes= e technicalities. Well=2C at least=2C that is how I feel
>=3B >=3B &= gt=3B about it.
>=3B >=3B >=3B
>=3B >=3B >=3B BIP39 and = Electrum v2 have a very different ways of handling future
>=3B >=3B = >=3B innovation. Electrum v2 seed phrases include an explicit version num= ber=2C
>=3B >=3B >=3B that indicates how the wallet addresses shou= ld be derived. In contrast=2C
>=3B >=3B >=3B BIP39 seed phrases do= not include a version number at all. BIP39 is
>=3B >=3B >=3B mean= t to be combined with BIP43=2C which stipulates that the wallet
>=3B &= gt=3B >=3B structure should depend on the BIP32 derivation path used for = the wallet
>=3B >=3B >=3B (although BIP43 is not followed by all B= IP39 compatible wallets). Thus=2C
>=3B >=3B >=3B innovation in BIP= 43 is allowed only within the framework of BIP32. In
>=3B >=3B >= =3B addition=2C having to explore the branches of the BIP32 tree in order t= o
>=3B >=3B >=3B determine the type of wallet attached to a seed m= ight be somewhat
>=3B >=3B >=3B inefficient.
>=3B >=3B >= =3B
>=3B >=3B >=3B The second problem I see with BIP39 is that it= requires a fixed
>=3B >=3B >=3B wordlist. Of course=2C this forbi= ds innovation in the wordlist itself=2C but
>=3B >=3B >=3B that's = not the main problem. When you write a new standard=2C it is
>=3B >= =3B >=3B important to keep this standard minimal=2C given the goal you wa= nt to
>=3B >=3B >=3B achieve. I believe BIP39 could (and should) h= ave been written without
>=3B >=3B >=3B including the wordlist in = the standard.
>=3B >=3B >=3B
>=3B >=3B >=3B There are tw= o ways to derive a master key from a mnemonic phrase:
>=3B >=3B >= =3B  =3B1. A bidirectional mapping between words and numbers=2C as in o= ld
>=3B >=3B >=3B Electrum versions. Pros: bidirectional means tha= t you can do Shamir
>=3B >=3B >=3B secret sharing of your seed. Co= ns: It requires a fixed wordlist.
>=3B >=3B >=3B  =3B2. Use a = hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
>=3B &g= t=3B >=3B required. Cons: the mapping isn't bidirectional.
>=3B >= =3B >=3B
>=3B >=3B >=3B Electrum v1 uses (1). Electrum v2 uses = (2).
>=3B >=3B >=3B
>=3B >=3B >=3B Early versions of BIP= 39 used (1)=2C and later they switched to (2).
>=3B >=3B >=3B Howe= ver=2C BIP39 uses (2) only in order to derive the wallet keys=2C not for>=3B >=3B >=3B its checksum. The BIP39 checksum uses (1)=2C and it d= oes requires a fixed
>=3B >=3B >=3B wordlist. This is just plainly= inconsistent. As a result=2C you have
>=3B >=3B >=3B neither word= list flexibility=2C nor Shamir secret sharing.
>=3B >=3B >=3B
= >=3B >=3B >=3B Having a fixed wordlist is very unfortunate. First=2C = it means that BIP39
>=3B >=3B >=3B will probably never leave the '= draft' stage=2C until all languages of the
>=3B >=3B >=3B world ha= ve been added. Second=2C once you add a wordlist for a new
>=3B >=3B= >=3B language=2C you cannot change it anymore=2C because it will break e= xisting
>=3B >=3B >=3B seed phrases=3B therefore you have to be ex= tremely careful in the way you
>=3B >=3B >=3B design these wordlis= ts. Third=2C languages often have words in common.
>=3B >=3B >=3B = When you add a new language to the list=2C you should not use words
>= =3B >=3B >=3B already used by existing wordlists=2C in order to ensure = that the language
>=3B >=3B >=3B can be detected. It leads to a fi= rst come first served situation=2C that
>=3B >=3B >=3B might not b= e sustainable in the future.
>=3B >=3B >=3B
>=3B >=3B >= =3B In order to support the old Electrum v1 seeds=2C all future versions of=
>=3B >=3B >=3B Electrum will have to include the old wordlist. In= addition=2C when
>=3B >=3B >=3B generating new seed phrases=2C El= ectrum now has to avoid collisions with
>=3B >=3B >=3B old seed ph= rases=2C because the old ones did not have a version number.
>=3B >= =3B >=3B This is painful enough=2C I will not repeat the same errors twic= e.
>=3B >=3B >=3B
>=3B >=3B >=3B Electrum v2 derives bot= h its private keys and its checksum/version
>=3B >=3B >=3B number = using a hash of the seed phrase. This means that wordlists can be
>=3B= >=3B >=3B added and modified in the future=2C without breaking existin= g seed
>=3B >=3B >=3B phrases. It also means that it will be very = easy for other wallets to
>=3B >=3B >=3B support Electrum seedphra= ses: it requires about 20 lines of code=2C and no
>=3B >=3B >=3B w= ordlist is required."
>=3B >=3B >=3B
>=3B >=3B >=3B
= >=3B >=3B >=3B Thomas
>=3B >=3B >=3B
>=3B >=3B >= =3B
>=3B >=3B >=3B Le 02/03/2015 16:37=2C Mike Hearn a =E9crit :<= br>>=3B >=3B >=3B >=3B Congrats Thomas! Glad to see Electrum 2 fina= lly launch.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B =
>=3B >=3B >=3B >=3B>=3B * New seed derivation method (not com= patible with BIP39).
>=3B >=3B >=3B >=3B
>=3B >=3B >= =3B >=3B
>=3B >=3B >=3B >=3B Does this mean a "12 words" wall= et created by Electrum won't work if
>=3B >=3B >=3B >=3B importe= d into some other wallet that supports BIP39? Vice versa? This seems
>= =3B >=3B >=3B >=3B unfortunate. I guess if seeds are being represente= d with 12 words
>=3B >=3B >=3B >=3B consistently=2C people will = expect them to work everywhere.
>=3B >=3B >=3B >=3B
>=3B &= gt=3B >=3B
>=3B >=3B >=3B -------------------------------------= -----------------------------------------
>=3B >=3B >=3B Dive into= the World of Parallel Programming The Go Parallel Website=2C sponsored
= >=3B >=3B >=3B by Intel and developed in partnership with Slashdot Me= dia=2C is your hub for all
>=3B >=3B >=3B things parallel software= development=2C from weekly thought leadership blogs to
>=3B >=3B &g= t=3B news=2C videos=2C case studies=2C tutorials and more. Take a look and = join the
>=3B >=3B >=3B conversation now. http://goparallel.sourc= eforge.net/
>=3B >=3B >=3B _______________________________________= ________
>=3B >=3B >=3B Bitcoin-development mailing list
>=3B= >=3B >=3B Bitcoin-development@lists.sourceforge.net
>=3B >=3B &= gt=3B Bitcoin-development --
>=3B >=3B >=3B |  =3B |
>=3B= >=3B >=3B |  =3B |  =3B |  =3B |  =3B |  =3B |
= >=3B >=3B >=3B | Bitcoin-development --To see the collection of prior= postings to the list=2C visit the Bitcoin-development Archives. |
>= =3B >=3B >=3B | =3B |
>=3B >=3B >=3B | View on lists.sourc= eforge.net | Preview by Yahoo |
>=3B >=3B >=3B | =3B |
>= =3B >=3B >=3B |  =3B |
>=3B >=3B >=3B
>=3B >=3B &g= t=3B =3B  =3B
>=3B >=3B >=3B
>=3B >=3B >=3B = =3B
>=3B >=3B >=3B =3B =3B =3B
>=3B >=3B
= >=3B >=3B >=3B ------------------------------------------------------= ------------------------
>=3B >=3B >=3B Dive into the World of Par= allel Programming The Go Parallel Website=2C sponsored
>=3B >=3B >= =3B by Intel and developed in partnership with Slashdot Media=2C is your hu= b for all
>=3B >=3B >=3B things parallel software development=2C f= rom weekly thought leadership blogs to
>=3B >=3B >=3B news=2C vide= os=2C case studies=2C tutorials and more. Take a look and join the
>= =3B >=3B >=3B conversation now. http://goparallel.sourceforge.net/
&= gt=3B >=3B
>=3B >=3B >=3B _____________________________________= __________
>=3B >=3B >=3B Bitcoin-development mailing list
>= =3B >=3B >=3B Bitcoin-development@lists.sourceforge.net
>=3B >= =3B >=3B https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
>=3B
>=3B -----------------------------------------------------= -------------------------
>=3B Dive into the World of Parallel Program= ming The Go Parallel Website=2C sponsored
>=3B by Intel and developed = in partnership with Slashdot Media=2C is your hub for all
>=3B things = parallel software development=2C from weekly thought leadership blogs to>=3B news=2C videos=2C case studies=2C tutorials and more. Take a look a= nd join the
>=3B conversation now. http://goparallel.sourceforge.net/=
>=3B _______________________________________________
>=3B Bitcoi= n-development mailing list
>=3B Bitcoin-development@lists.sourceforge.= net
>=3B https://lists.sourceforge.net/lists/listinfo/bitcoin-developm= ent
= --_1192efe0-4738-4ad6-a708-b47acfd53f0b_--