making seeds non-BIP39 compatible

[wizardofozzie]

@ecdsa I propose that all Electrum 2.x mnemonic seeds are generated such that the 12 word phrases generated are NOT BIP39 compatible. It would clearly delineate Electrum 2.x from BIP39.
@gurnec provides the loss in entropy as <0.05 bits at the SE discussion

[ecdsa]

I believe 12-word seeds are more user friendly than 13-word seeds.
We currently have 13 words seeds because of the size of the wordlist.
I plan to increase the size of the wordlist in order to get back to 12 words seeds without loss of entropy.

[gurnec]

In order to guarantee that current Electrum 2.x seeds are not BIP-39 valid, Electrum would have to (now and forever more) ship with the BIP-39 word lists. Avoiding being tied to / having to maintain any particular word list was I think one of the reasons behind Electrum 2.x's choices....

As an alternative, if a new longer (at least 2581 words) list is created for 12-word seeds, it could be created with no shared words with BIP-39. Of course, generating a decent such list is non-trivial....

[ecdsa]

A better solution is for other wallets to stop using BIP39.
BIP39 is a failed design, and this is not an Electrum issue.

[ecdsa]

OTOH if you insist on using BIP39, it is trivial to ensure that your seeds are non-electrum compatible, you don't need a wordlist for that; you just need a hash.

[gurnec]

A better solution is for other wallets to stop using BIP39. [...] this is not an Electrum issue.

FWIW I agree.

I think the only bullet-proof solution is for @simcity4242 to "bite the bullet" and do a is_electrum2_mnemonic(), is_bip39_mnemonic(), etc. and force the user to select a type if an ambiguity is found (and likewise for ambiguities between BIP-39 word lists).

BIP39 is a failed design,

I don't want to start an argument... I'd just say "inferior" IMHO.

[wizardofozzie]

A better solution is for other wallets to stop using BIP39.

Agreed, to a certain extent. I'm just trying to be pragmatic about standards. From an outsider perspective, a mnemonic phrase should work without having to know:

1. the standard (BIP39, Electrum etc)
2. standard's version (Electrum 1 or 2, for eg)
3. language (some BIP39 word lists have ambiguities)

it is trivial to ensure that your seeds are non-electrum compatible, you don't need a wordlist for that; you just need a hash.

It is, you're right. I'm putting it to Electrum though, because as the source code mentions, "Electrum departs from BIP39 compatibility" (paraphrased). So, if you're departing from compatibility, why not clearly delineate Electrum seeds from what you, yourself, calls "a broken standard" (ie BIP39)?

In order to guarantee that current Electrum 2.x seeds are not BIP-39 valid, Electrum would have to (now and forever more) ship with the BIP-39 word lists. Avoiding being tied to / having to maintain any particular word list was I think one of the reasons behind Electrum 2.x's choices....

@gurnec Yes, very good point

[andronoob]

@ecdsa I wonder if the ambiguity avoided (during Electrum 2.0 seed generation)/handled (during seed importing)?

---

A better solution is for other wallets to stop using BIP39.
BIP39 is a failed design, and this is not an Electrum issue.

"Failed" or not, plenty of users have been on this boat. Besides, there are still plenty of wallets which implement BIP39 currently, including popular ones.

Anyway, every wallet potentially has to take care about what other wallets have been doing, otherwise it simply breaks interoperability. In my opinion BIP39 is at least not so bad from this aspect, because the ugly approach of "magical string called derivation path" can work to some extent at least.

Sigh... It seems that the WIF pirvkey fetishism/maximalism would inevitably continue to exist... which is a desperate fact that a random troll like me can do nothing to change...

---

I have to agree that BIP39 has a fatal "flaw" that it's not invertible (the mnemonic words have to be one-way hashed to generate the BIP32 entropy), which means even conversion among different languages (English/Japanese/Spanish/Korean/Chinese...etc) is not possible either, let alone converting from other seeds.

In other words, BIP39 is just as "exclusive" as other incompatible seed formats, including but not limited to Electrum 2.0, aezeed, or something other, in the sense that, like, a seed can't be both BIP39 and Electrum 2.0 at same time - even if it seems to be, a BIP39 compliant wallet still won't derive the "root" raw entropy of Electrum.

I wish that some invertible "encoding-like" design of mnemonic could emerge, so that the fragmented situation might be relieved. But I'm not sure whether this idea is fatally flawed in some other unexpected ways, too.

@aantonop I'm nobody in this field. It's likely that such a simple/naive idea is not fresh at all. I'm sorry for disturbance, however, I'm still curious whether this could be a way out.

Edit: In fact I have to agree with @ecdsa that "not an Electrum issue". Stopping developers from designing better seed formats is actually unreasonable. It also doesn't seem fair for Electrum alone to face all the hassles caused by the fragmented status quo. The same problem exists for any other wallets as well. What we needs is probably not limited to a new Electrum plugin/feature (like #6155 ) only.

[andronoob]

Finally, #6001 is going to avoid "BIP39-Electrum2.0 duality" - however I recently realized that even Electrum can do its best to avoid such ambiguity, Electrum itself still cannot stop other BIP39 wallets (which don't take Electrum 2.0 seed into consideration) to generate BIP39 mnemonics which are accidentally a valid Electrum2.0 seed at same time, although the probaility of the later case is very low (about 0.439%)