<oembed><type>rich</type><version>1.0</version><author_name>npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47</author_name><author_url>https://nostr.ae/npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-03-11&#xA;📝 Original message:Thanks Mike, and sorry to answer a bit late; it has been a busy couple&#xA;of weeks.&#xA;&#xA;You are correct, a BIP39 seed phrase will not work in Electrum, and vice&#xA;versa. It is indeed unfortunate. However, I believe BIP39 should not be&#xA;followed, because it reproduces two mistakes I did when I designed the&#xA;older Electrum seed system. Let me explain.&#xA;&#xA;The first problem I have with BIP39 is that the seed phrase does not&#xA;include a version number.&#xA;&#xA;Wallet development is still in an exploratory phase, and we should&#xA;expect even more innovation in this domain. In this context, it is&#xA;unwise to make decisions that prevent future innovation.&#xA;&#xA;However, when we give a seed phrase to users, we have a moral obligation&#xA;to keep supporting this seed phrase in future versions. We cannot simply&#xA;announce to Electrum users that their old seed phrase is not supported&#xA;anymore, because we created a new version of the software that uses a&#xA;different derivation. This could lead to financial losses for users who&#xA;are unaware of these technicalities. Well, at least, that is how I feel&#xA;about it.&#xA;&#xA;BIP39 and Electrum v2 have a very different ways of handling future&#xA;innovation. Electrum v2 seed phrases include an explicit version number,&#xA;that indicates how the wallet addresses should be derived. In contrast,&#xA;BIP39 seed phrases do not include a version number at all. BIP39 is&#xA;meant to be combined with BIP43, which stipulates that the wallet&#xA;structure should depend on the BIP32 derivation path used for the wallet&#xA;(although BIP43 is not followed by all BIP39 compatible wallets). Thus,&#xA;innovation in BIP43 is allowed only within the framework of BIP32. In&#xA;addition, having to explore the branches of the BIP32 tree in order to&#xA;determine the type of wallet attached to a seed might be somewhat&#xA;inefficient.&#xA;&#xA;The second problem I see with BIP39 is that it requires a fixed&#xA;wordlist. Of course, this forbids innovation in the wordlist itself, but&#xA;that&#39;s not the main problem. When you write a new standard, it is&#xA;important to keep this standard minimal, given the goal you want to&#xA;achieve. I believe BIP39 could (and should) have been written without&#xA;including the wordlist in the standard.&#xA;&#xA;There are two ways to derive a master key from a mnemonic phrase:&#xA; 1. A bidirectional mapping between words and numbers, as in old&#xA;Electrum versions. Pros: bidirectional means that you can do Shamir&#xA;secret sharing of your seed. Cons: It requires a fixed wordlist.&#xA; 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not&#xA;required. Cons: the mapping isn&#39;t bidirectional.&#xA;&#xA;Electrum v1 uses (1). Electrum v2 uses (2).&#xA;&#xA;Early versions of BIP39 used (1), and later they switched to (2).&#xA;However, BIP39 uses (2) only in order to derive the wallet keys, not for&#xA;its checksum. The BIP39 checksum uses (1), and it does requires a fixed&#xA;wordlist. This is just plainly inconsistent. As a result, you have&#xA;neither wordlist flexibility, nor Shamir secret sharing.&#xA;&#xA;Having a fixed wordlist is very unfortunate. First, it means that BIP39&#xA;will probably never leave the &#39;draft&#39; stage, until all languages of the&#xA;world have been added. Second, once you add a wordlist for a new&#xA;language, you cannot change it anymore, because it will break existing&#xA;seed phrases; therefore you have to be extremely careful in the way you&#xA;design these wordlists. Third, languages often have words in common.&#xA;When you add a new language to the list, you should not use words&#xA;already used by existing wordlists, in order to ensure that the language&#xA;can be detected. It leads to a first come first served situation, that&#xA;might not be sustainable in the future.&#xA;&#xA;In order to support the old Electrum v1 seeds, all future versions of&#xA;Electrum will have to include the old wordlist. In addition, when&#xA;generating new seed phrases, Electrum now has to avoid collisions with&#xA;old seed phrases, because the old ones did not have a version number.&#xA;This is painful enough, I will not repeat the same errors twice.&#xA;&#xA;Electrum v2 derives both its private keys and its checksum/version&#xA;number using a hash of the seed phrase. This means that wordlists can be&#xA;added and modified in the future, without breaking existing seed&#xA;phrases. It also means that it will be very easy for other wallets to&#xA;support Electrum seedphrases: it requires about 20 lines of code, and no&#xA;wordlist is required.&#xA;&#xA;&#xA;Thomas&#xA;&#xA;&#xA;Le 02/03/2015 16:37, Mike Hearn a écrit :&#xA;&gt; Congrats Thomas! Glad to see Electrum 2 finally launch.&#xA;&gt; &#xA;&gt; &#xA;&gt;&gt; * New seed derivation method (not compatible with BIP39).&#xA;&gt; &#xA;&gt; &#xA;&gt; Does this mean a &#34;12 words&#34; wallet created by Electrum won&#39;t work if&#xA;&gt; imported into some other wallet that supports BIP39? Vice versa? This seems&#xA;&gt; unfortunate. I guess if seeds are being represented with 12 words&#xA;&gt; consistently, people will expect them to work everywhere.&#xA;&gt;</html></oembed>