diff options
| author | Thy Shizzle <thashiznets@yahoo.com.au> | 2015-03-12 04:21:59 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-12 04:22:07 +0000 |
| commit | 786d7fe07cd9cb69a0a97500a2ddaf04ed573686 (patch) | |
| tree | fd6d25ddac09b7e3744765990227c3a459608fcd | |
| parent | 08065309644b0607e4ca590d8d4fc212b4e506f6 (diff) | |
| download | pi-bitcoindev-786d7fe07cd9cb69a0a97500a2ddaf04ed573686.tar.gz pi-bitcoindev-786d7fe07cd9cb69a0a97500a2ddaf04ed573686.zip | |
Re: [Bitcoin-development] Electrum 2.0 has been tagged
| -rw-r--r-- | ab/994265f48b202dd13cac13e661d689f415de41 | 559 |
1 files changed, 559 insertions, 0 deletions
diff --git a/ab/994265f48b202dd13cac13e661d689f415de41 b/ab/994265f48b202dd13cac13e661d689f415de41 new file mode 100644 index 000000000..0b451a388 --- /dev/null +++ b/ab/994265f48b202dd13cac13e661d689f415de41 @@ -0,0 +1,559 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <harro84@yahoo.com.au>) id 1YVudL-00023K-Pm + for Bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 04:22:07 +0000 +Received: from nm22-vm1.bullet.mail.bf1.yahoo.com ([98.139.212.127]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YVudJ-0004hE-G6 + for Bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 04:22:07 +0000 +Received: from [98.139.215.143] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; + 12 Mar 2015 04:22:00 -0000 +Received: from [98.139.212.250] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; + 12 Mar 2015 04:22:00 -0000 +Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; + 12 Mar 2015 04:22:00 -0000 +X-Yahoo-Newman-Property: ymail-3 +X-Yahoo-Newman-Id: 125879.76669.bm@omp1059.mail.bf1.yahoo.com +X-YMail-OSG: NcNhypsVM1kbbGJhwiZNu_nQu1yIBC1hTTRtDazdk7L4f7efr7xQnVJydLVQ7DU + fcJR22M9JYfEV43Smzr7nMI0N6Dih6Ry5Xc2aRnScfRmPh63OJbUy0is0r4FBtOBcx_llYuS0Eo7 + pTpFLviDk2RKPSXu93vRkzmcP3BvexqtLqy7KFBxHNwb4Vw_7xLP9XzU_WelyBFYxqt16vkkChCO + 2bzEFZpJsoNN3KKwhryBuWV6QRdu5Ps.EirmXgHwk86KLX2OH7kfJiDgsL3AfsPX.YvQo4EpS2Uy + aeT94bE3bdVvMIYrFOiOb4G7ooXwUrfI.kmEQtGptjMZryuLsuNaEq4z9ltyCaSCML7QDu9opDZy + TBmRKd4HztiTPuMYcYSw4caiT_oxdGGrGLQi.lapehn1LX.0pYch8r8C9Igk3MBXTtimEqvwVSj5 + 6y9NBBhyldwHsIxCPVWB10QFMq6DC8n1JKuE70mINMX.8rknANECikFMr3OS0yL7G0oi.wsFnVqi + E0vmJqdHA9wxCuQZpr6BZulV5lbZE.1GBJdZsWMDfzTgUOc69VDjFptAdcRtXGrwRIZ8fYZZPmeD + ay7YCcBdFD7PusouJkDtKBQ-- +Received: by 76.13.27.6; Thu, 12 Mar 2015 04:21:59 +0000 +Date: Thu, 12 Mar 2015 04:21:59 +0000 (UTC) +From: Thy Shizzle <thashiznets@yahoo.com.au> +To: "neillm@thecodefactory.org" <neillm@thecodefactory.org> +Message-ID: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com> +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----=_Part_4537987_2002390733.1426134119099" +X-Spam-Score: 1.2 (+) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (harro84[at]yahoo.com.au) + 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in + digit (harro84[at]yahoo.com.au) + 1.0 HTML_MESSAGE BODY: HTML included in message + -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 + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [98.139.212.127 listed in list.dnswl.org] + 0.0 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1YVudJ-0004hE-G6 +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 +Reply-To: Thy Shizzle <thashiznets@yahoo.com.au> +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 04:22:07 -0000 + +------=_Part_4537987_2002390733.1426134119099 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +=C2=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" +^ This is incorrect I think Neill, the reason is that the only thing that h= +appens when you change the wordlist is that entropy points to different wor= +ds. But remember, entropy is disposed. Yes in my code I allow for the keepi= +ng of entropy etc, it also lets me "hot swap" between different language wo= +rdlists etc but in real world implementation the entropy is forgotten and n= +ot stored. So changing the wordlist merely allows new mnemonic phrases to b= +e generated but it has a nil impact on previously generated mnemonics UNLES= +S you are trying to rebuild from entropy but you wouldn't do that. You woul= +d be rebuilding from the Mnemonic in real world scenario. You really can ha= +ve a word list of total rubbish in BIP39 as long as it is 2048 words long t= +hat 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 rwetr= +tr" and no matter what BIP39 implementation you put it in, it will always g= +enerate the same seed bytes thus allowing for complete and universal seed d= +erivation without any reliance on word list. The word list is merely to gen= +erate a mnemonic, after that it has no role in seed generation so you can c= +hange it at anytime 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, what= +ever mnemonic you provide will always generate the same seed, BIP39 is 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).=C2=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). + +> Version is something that can be dealt with after the fact, hopefully sta= +ndardised (curious why didn't you work with the BIP39 to insert version ins= +tead 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).=C2=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. + +-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 simpli= +fied and traditional, but I found it easy to look for a word in the mnemoni= +c that is unique to that language/wordlist and so straight away you can det= +ermine the language, remembering you get minimum 12 goes at doing that :) +> Also then I asked myself, do we really care about detecting the language?= + Probably not because we don't need to use the wordlist ever again after cr= +eation, 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 woul= +d take almost no effort to put it in and I think you should do that :) I do= +n't have any interest in BIP39 other than it being a standard. I think TREZ= +OR 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: +> =C2=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. +> =C2=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 =C3=A9crit : +> > 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 s= +eems +> > 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, spon= +sored +> by Intel and developed in partnership with Slashdot Media, is your hub fo= +r all +> things parallel software development, from weekly thought leadership blog= +s 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 -- +> | =C2=A0 | +> | =C2=A0 | =C2=A0 | =C2=A0 | =C2=A0 | =C2=A0 | +> | Bitcoin-development --To see the collection of prior postings to the li= +st, visit the Bitcoin-development Archives. | +> |=C2=A0 | +> | View on lists.sourceforge.net | Preview by Yahoo | +> |=C2=A0 | +> | =C2=A0 | +>=20 +>=C2=A0 =C2=A0 +>=20 +>=C2=A0=20 +>=C2=A0=C2=A0=C2=A0=20 + +> -------------------------------------------------------------------------= +----- +> Dive into the World of Parallel Programming The Go Parallel Website, spon= +sored +> by Intel and developed in partnership with Slashdot Media, is your hub fo= +r all +> things parallel software development, from weekly thought leadership blog= +s 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 + +------=_Part_4537987_2002390733.1426134119099 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<html><body><div style=3D"color:#000; background-color:#fff; font-family:He= +lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,= + Lucida Grande, Sans-Serif;font-size:16px"><div id=3D"yui_3_16_0_1_14261226= +60566_28256"> "I agree that it's true that a static wordlist is<br> re= +quired once people have started using BIP39 for anything real and<br> chang= +ing the word lists will invalidate any existing mnemonics"</div><div id=3D"= +yui_3_16_0_1_1426122660566_28554"><br></div><div id=3D"yui_3_16_0_1_1426122= +660566_28553" dir=3D"ltr">^ This is incorrect I think Neill, the reason is = +that the only thing that happens when you change the wordlist is that entro= +py points to different words. But remember, entropy is disposed. Yes in my = +code I allow for the keeping of entropy etc, it also lets me "hot swap" bet= +ween 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 UNLESS you are trying to rebuild from entropy but you = +wouldn't do that. You would be rebuilding from the Mnemonic in real world s= +cenario. 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 rwetrtr" and no matter what BIP39 implementation you p= +ut it in, it will always generate the same seed bytes thus allowing for com= +plete and universal seed derivation without any reliance on word list. The = +word list is merely to generate a mnemonic, after that it has no role in se= +ed generation so you can change it at anytime and it will never effect futu= +re mnemonics.</div><div id=3D"yui_3_16_0_1_1426122660566_28581" dir=3D"ltr"= +><br></div><div id=3D"yui_3_16_0_1_1426122660566_28255"><br></div><div id= +=3D"yui_3_16_0_1_1426122660566_28254">On Thu, Mar 12, 2015 at 02:16:38AM +0= +000, Thy Shizzle wrote:<br> +> That's disappointing the Electrum 2.0 doesn't use BIP39.<br> +<br> +Agreed, but I don't know the full background on this.<br> +<br> +> Changing the wordlist in the future has ZERO effect on derived seed, w= +hatever mnemonic you provide will always generate the same seed, BIP39 is n= +ot mapping the words back to numbers etc to derive seed.<br> +<br> +That's true for generating new mnemonics (i.e. same entropy can<br> +generate any combinations of words), but not for converting a mnemonic<br> +to a seed (i.e. a specific wordlist/passphrase should always generate<br> +the same seed). I agree that it's true that a static wordlist is<br> +required once people have started using BIP39 for anything real and<br> +changing the word lists will invalidate any existing mnemonics (unless<br> +your 'new' wordlist simply substitutes one word for another and the<br> +index mapping is made public ... which means it's not really an<br> +arbitrary word list).<br> +<br> +> Version is something that can be dealt with after the fact, hopefully = +standardised (curious why didn't you work with the BIP39 to insert version = +instead of do something different to BIP39?)<br> +> So most of what you are suggesting as problems are not.<br> +<br> +I don't see how this can work given the BIP39 spec as it is today<br> +(there's simply no room for a version in the bits). I do think<br> +versioning would be nice, but as of now, I'm in the camp that thinks<br> +complete wallet interoperability is a bit of a myth -- so long as you<br> +can fundamentally move into/out of wallets at will.<br> +<br> +-Neill.<br> +<br> +> As for the common words between languages, I have discussed this with = +the provider of the Chinese wordlists as they shared some words between sim= +plified and traditional, but I found it easy to look for a word in the mnem= +onic that is unique to that language/wordlist and so straight away you can = +determine the language, remembering you get minimum 12 goes at doing that := +)<br> +> Also then I asked myself, do we really care about detecting the langua= +ge? 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 w= +ould 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 T= +REZOR may have an interest in it?<br> +> Thomas V:<br> +> "Thanks Mike, and sorry to answer a bit late; it has been a busy coupl= +e<br> +> of weeks.<br> +> <br> +> You are correct, a BIP39 seed phrase will not work in Electrum, and vi= +ce<br> +> versa. It is indeed unfortunate. However, I believe BIP39 should not b= +e<br> +> followed, because it reproduces two mistakes I did when I designed the= +<br> +> older Electrum seed system. Let me explain.<br> +> <br> +> The first problem I have with BIP39 is that the seed phrase does not<b= +r> +> include a version number.<br> +> <br> +> Wallet development is still in an exploratory phase, and we should<br> +> expect even more innovation in this domain. In this context, it is<br> +> unwise to make decisions that prevent future innovation.<br> +> <br> +> However, when we give a seed phrase to users, we have a moral obligati= +on<br> +> to keep supporting this seed phrase in future versions. We cannot simp= +ly<br> +> announce to Electrum users that their old seed phrase is not supported= +<br> +> anymore, because we created a new version of the software that uses a<= +br> +> different derivation. This could lead to financial losses for users wh= +o<br> +> are unaware of these technicalities. Well, at least, that is how I fee= +l<br> +> about it.<br> +> <br> +> BIP39 and Electrum v2 have a very different ways of handling future<br= +> +> innovation. Electrum v2 seed phrases include an explicit version numbe= +r,<br> +> that indicates how the wallet addresses should be derived. In contrast= +,<br> +> BIP39 seed phrases do not include a version number at all. BIP39 is<br= +> +> meant to be combined with BIP43, which stipulates that the wallet<br> +> structure should depend on the BIP32 derivation path used for the wall= +et<br> +> (although BIP43 is not followed by all BIP39 compatible wallets). Thus= +,<br> +> innovation in BIP43 is allowed only within the framework of BIP32. In<= +br> +> addition, having to explore the branches of the BIP32 tree in order to= +<br> +> determine the type of wallet attached to a seed might be somewhat<br> +> inefficient.<br> +> <br> +> The second problem I see with BIP39 is that it requires a fixed<br> +> wordlist. Of course, this forbids innovation in the wordlist itself, b= +ut<br> +> that's not the main problem. When you write a new standard, it is<br> +> important to keep this standard minimal, given the goal you want to<br= +> +> achieve. I believe BIP39 could (and should) have been written without<= +br> +> including the wordlist in the standard.<br> +> <br> +> There are two ways to derive a master key from a mnemonic phrase:<br> +> 1. A bidirectional mapping between words and numbers, as in old<= +br> +> Electrum versions. Pros: bidirectional means that you can do Shamir<br= +> +> secret sharing of your seed. Cons: It requires a fixed wordlist.<br> +> 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist= + is not<br> +> required. Cons: the mapping isn't bidirectional.<br> +> <br> +> Electrum v1 uses (1). Electrum v2 uses (2).<br> +> <br> +> Early versions of BIP39 used (1), and later they switched to (2).<br> +> However, BIP39 uses (2) only in order to derive the wallet keys, not f= +or<br> +> its checksum. The BIP39 checksum uses (1), and it does requires a fixe= +d<br> +> wordlist. This is just plainly inconsistent. As a result, you have<br> +> neither wordlist flexibility, nor Shamir secret sharing.<br> +> <br> +> Having a fixed wordlist is very unfortunate. First, it means that BIP3= +9<br> +> will probably never leave the 'draft' stage, until all languages of th= +e<br> +> world have been added. Second, once you add a wordlist for a new<br> +> language, you cannot change it anymore, because it will break existing= +<br> +> seed phrases; therefore you have to be extremely careful in the way yo= +u<br> +> design these wordlists. Third, languages often have words in common.<b= +r> +> When you add a new language to the list, you should not use words<br> +> already used by existing wordlists, in order to ensure that the langua= +ge<br> +> can be detected. It leads to a first come first served situation, that= +<br> +> might not be sustainable in the future.<br> +> <br> +> In order to support the old Electrum v1 seeds, all future versions of<= +br> +> Electrum will have to include the old wordlist. In addition, when<br> +> generating new seed phrases, Electrum now has to avoid collisions with= +<br> +> old seed phrases, because the old ones did not have a version number.<= +br> +> This is painful enough, I will not repeat the same errors twice.<br> +> <br> +> Electrum v2 derives both its private keys and its checksum/version<br> +> number using a hash of the seed phrase. This means that wordlists can = +be<br> +> added and modified in the future, without breaking existing seed<br> +> phrases. It also means that it will be very easy for other wallets to<= +br> +> support Electrum seedphrases: it requires about 20 lines of code, and = +no<br> +> wordlist is required."<br> +> <br> +> <br> +> Thomas<br> +> <br> +> <br> +> Le 02/03/2015 16:37, Mike Hearn a =C3=A9crit :<br> +> > Congrats Thomas! Glad to see Electrum 2 finally launch.<br> +> > <br> +> > <br> +> >> * New seed derivation method (not compatible with BIP39).<br> +> > <br> +> > <br> +> > Does this mean a "12 words" wallet created by Electrum won't work= + if<br> +> > imported into some other wallet that supports BIP39? Vice versa? = +This seems<br> +> > unfortunate. I guess if seeds are being represented with 12 words= +<br> +> > consistently, people will expect them to work everywhere.<br> +> > <br> +> <br> +> ----------------------------------------------------------------------= +--------<br> +> Dive into the World of Parallel Programming The Go Parallel Website, s= +ponsored<br> +> by Intel and developed in partnership with Slashdot Media, is your hub= + for all<br> +> things parallel software development, from weekly thought leadership b= +logs to<br> +> news, videos, case studies, tutorials and more. Take a look and join t= +he <br> +> conversation now. <a tabindex=3D"-1" href=3D"http://goparallel.sourcef= +orge.net/" target=3D"_parent"><font color=3D"#0066cc">http://goparallel.sou= +rceforge.net/</font></a><br> +> _______________________________________________<br> +> Bitcoin-development mailing list<br> +> Bitcoin-development@lists.sourceforge.net<br> +> Bitcoin-development --<br> +> | |<br> +> | | | | | |<br> +> | Bitcoin-development --To see the collection of prior postings to the= + list, visit the Bitcoin-development Archives. |<br> +> | |<br> +> | View on lists.sourceforge.net | Preview by Yahoo |<br> +> | |<br> +> | |<br> +> <br> +> <br> +> <br> +> <br> +> <br> +<br> +> ----------------------------------------------------------------------= +--------<br> +> Dive into the World of Parallel Programming The Go Parallel Website, s= +ponsored<br> +> by Intel and developed in partnership with Slashdot Media, is your hub= + for all<br> +> things parallel software development, from weekly thought leadership b= +logs to<br> +> news, videos, case studies, tutorials and more. Take a look and join t= +he <br> +> conversation now. <a tabindex=3D"-1" href=3D"http://goparallel.sourcef= +orge.net/" target=3D"_parent"><font color=3D"#0066cc">http://goparallel.sou= +rceforge.net/</font></a><br> +<br> +> _______________________________________________<br> +> Bitcoin-development mailing list<br> +> Bitcoin-development@lists.sourceforge.net<br> +> <a tabindex=3D"-1" href=3D"https://lists.sourceforge.net/lists/listinf= +o/bitcoin-development" target=3D"_parent"><font color=3D"#0066cc">https://l= +ists.sourceforge.net/lists/listinfo/bitcoin-development</font></a><br> +</div></div></body></html> +------=_Part_4537987_2002390733.1426134119099-- + + |