Quote from: pooya87 on October 16, 2020, 05:23:32 AM

recovery using mnemonic (which was supposed to be easy) becomes hard.

No, it's not hard at all. With standard derivation paths including BIP44/49/84 etc, it works pretty well, across multiple wallets made by different vendors.

Even if the nonstandard paths are taken into consideration, it's still not bad - almostly the only thing you need is merely a string called "derivation path" - which is what Electrum, a BIP39-supporting-but-disliking wallet, has been doing up till now. There are only few exceptions like Bitcoin Core's hardened address derivation, which also seems to be easy cases to cover to me. Besides, there're no extra executable binaries to download, so that no need to worry about malwares.

The what about the so-called "fixes" to BIP39's so-called flaws?

In my opinion, obviously a chaotic ecosystem with many competing incompatible mnemonic schemes is really making users feeling bad - as a user you generally can't show the word to some random expert to determine WTF it is, because it's obviously confidential.

What's more, some "BIP39-killing" seed standards, like Electrum 2.0 seed and aezeed, share exactly the same word list with BIP39. Then what happens? Those ambiguous seed standards almostly effectively become yet another (much-blamed) "nonstandard derivation paths" themselves...

Quote from: pooya87 on October 16, 2020, 05:23:32 AM

the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing

After thinking about this problem, I think it's reasonable for a dev to feel bad about dealing with sh*ts (of unimaginable infinite possibilities) produced by other devs, or just themselves in the past. It's also not too bad (although it is definitely bad IMO, like outlined above) if different seed standards exclusively reject with each other. It should be not-so-bad (still bad, but also still ideal/better situation than the status quo, that devs tends to discriminate, or even ignore other disliked seed standards) that every wallet also take good care of other seed standards, but this requires efforts for the devs to implement and maintain.

However, unfortunately some (supposed) "BIP39-killer" seed standards like Electrum 2.0 and aezeed don't seem to be good precedences, because they are BIP39-ambiguous.

In my opinion, the "lack of version/type bits" is on the contrary a feature rather than a flaw - it means that you can adopt new coin types/address types/"accounts" (isolated subgroups of addresses) without redoing the boring backup job once again.

However I also admit that in a case the user want to destroy a backup, a forgotten derivation path/coin type/address type etc can be really destructive - although in my opinion it's just what bitcoin has been from the very beginning - even Satoshi himself said that "you should never delete a private key". Besides, I also admit that destroying an old mnemonic with forgotten funds is not the only possibility, leaking to the public is also a possible threat.

Also, although BIP44/49/84 provides isolation amoung different address types/coin types/"accounts", I admit that such isolation is likely to be simply bypassed by bad habit of carelessly importing the mnemonic (which is the "root" of everything) everywhere.

Quote from: pooya87 on October 16, 2020, 05:23:32 AM

the word-lists and their inconsistency is mainly because over the years new lists were added and over the years the rules for new ones were improved requiring more unique lists with distinct words.

To check validity of a BIP39 mnemonic, a corresponding word list is needed - so what if word list is not known? BIP39 said: oh, maybe, maybe... you can just ignore it. Grin

"maybe just ignore it" - that's the blamed inconsistency of BIP39.
To my understanding it's not strictly about more and more languages being added, because wallet can still use the newly added word list to check the validity.
The one-way hash of BIP39 also disallowed conversion among different languages, so to summarize, it ruined both the advantage of one-way hash (so that checking validity won't need a word list) and the advantage of "bijective encoding" (for example, there might be awkward situations like inability to input CJK characters - this issue still seems to present even if it's bijectively encoded, however conversion might still be useful. also, it seems to be nice to directly encode an existing HD master node).

However, I don't think these problems are fatal.

To summarize, I don't consider BIP39 perfect either. However I just don't want to see the "fix BIP39 by killing BIP39" story to happen again, only adding yet another incompatible (or even worse, ambiguous) seed standard to the whole ecosystem, without bringing much benefits/new features (like Shamir's Secret Sharing etc).