Electrum's native seeds are not BIP39. The reasoning behind this is given in this post on the bitcoin development mailing list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013061.html
So you can only restore an electrum wallet in electrum. You can restore a mycelium wallet in electrum as Potato Chips said above. You just have to click on options and check bip39 when you get to the seed entry screen during the wallet creation process.
Yes, bip39 is a child of chaos, created in confusion.https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013061.html
So you can only restore an electrum wallet in electrum. You can restore a mycelium wallet in electrum as Potato Chips said above. You just have to click on options and check bip39 when you get to the seed entry screen during the wallet creation process.
BIP39 wordlist was a great idea, and executed as a horrible kludge.
https://bitcointalksearch.org/topic/m.9254301
All this confusion about incompatible wallets calls for a closer look at bip 39. The process starts with finding 128 bits of entropy ("ENT") and builds from there. The bip sets out some fairly simple steps for generating a wordlist from ENT. So far so good.
Then instead of creating the wallet seed from ENT, the simplest and best course, it goes like this
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
These steps are unnecessary, create extra work, and will lead to complications.
Encrypting your wordlist is all for the best, but please don't interpose that encryption between the originating entropy pool and the master seed/private key of the HD wallet. Basically you are encrypting entropy. It doesn't work like that. It ought to work like this:
The entropy is the seed.
Use it: entropy --> seed
ENT --> sha256 hash --> master privkey
To which voisine answered: "This was added so wallets could generate the seed even if they don't have or can't hold every word list, like trezor. I agree that it's less than ideal."
To which I answer: There's nothing to stop any wallet designer, who so wishes, from encoding the binary in a word list per bip39. As for interoperability among different wallets with different dictionaries... any wallet, even one as limited as trezor, is sure to have enough memory and processing power to decode its own word list. No wallet has to store a library of word lists.
Bip39 was kludged into the wallet architecture between the entropy and the master key -- where it isn't needed, and can only cause problems. Will we be stuck with this contraption in every wallet from now on, or will people get some sense into their heads?
Whoever came up that whole mess described in the section of the mediawiki titled "From mnemonic to seed" was wasting everybody's time. The idea that you have to go to such lengths to avoid storing a library of bip39 dictionaries is an illusion. Let the wallet store its own dictionary merely; when you need the binary, decode the wordlist. Simple as that!
HD wallet designers have followed the bip despite the bip's bad design.
And it is the worst kind of bad design; it's a strategic error not a coding blunder, so people operating on autopilot don't see it. Then it gets coded into wallets, and you're stuck with it forever. And we'll have all kinds of headaches making HD wallets compatible.
Abussamad, in the link that you provided, Thomas Voegtlin says "I personally believe that BIP39/BIP44 is a bad design."
I agree wholeheartedly.
The next HD wallet designer should ditch that horrifying abortion where the binary seed is created from the wordlist. That's totally backwards. Simply use the entropy or pseudorandom number you started with.
