Quote from: pooya87 on Today at 06:04:47 AM

You keep using the term "standard" while there is no such thing in bitcoin.

To me, it doesn't matter which word to use. If you feel uncomforatble about the word "standard", maybe I could replace it with something else, like "specification", "proposal" etc?

Quote from: pooya87 on Today at 06:04:47 AM

There is no centralized authority forming a standard committee defining what must or mustn't be used. Any developer decides what is the most appropriate approach and uses that instead.

Then it just turns out that, freedom/permissionless has its inevitable price to pay - a chaotic ecosystem which has been confusing/frustrating users up till now... Okay, okay, I'll stop here, I don't want to troll. Nobody (including me) can force any dev to change his mind to adopt anything (including BIP39) - however, in my opinion, if every dev designs his own awesome (/s) mnemonic scheme, then the users will simply get headache -again, they don't know WTF the mnemonic phrase at their hand is, they can't show it to some random experts on the Internet either (because it's confidential - anyone knows the mnemonic can instantly steal the funds locked by it).

Quote from: pooya87 on Today at 06:04:47 AM

In fact these differences are a good indication of existing flaws in mnemonic algorithms. (everyone is trying to address them in their own way).

I know the imperfections of BIP39. I've already said that imperfections != fatal flaws.

Especially, I don't see those "BIP39-killers" like Electrum 2.0 can "fix" the so-called flaws of BIP39 - at least BIP39 hasn't been killed up till now. Countless users rely on it. You can't let BIP39 poof overnight. And, BIP39 works - I don't think it's necessary to kill it either.

"BIP39-killers" can't kill BIP39 - on the contrary those "BIP39-killers" themselves can't be killed either, which is ironically exactly the same case of BIP39.

In my opinion, ideally every wallet shoud take care of every mnemonic scheme, including either BIP39 or Electrum2.0, aezeed etc, however in reality this doesn't seem to happen for now, that's why users got frustrated/confused.

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

This problem is not particularly created by devs, it is introduced at a later time when new scripts were introduced to bitcoin.
...
You also have to see this from the eyes of people who aren't familiar with many details of bitcoin. There are those who don't know what P2WPKH means let alone want to select it when recovering their wallet from mnemonic.

SegWit is another different topic. I can totally blame SegWit for the new commonly/widely used address/script types it had introduced to bitcoin, which forces the users to learn more - as a lazy human, learning is painful, isn't it. Let alone the privacy implications brought by SegWit, like: different script type may reveal which output is the change.

However, I still don't want to blame SegWit, because as a soft-fork upgrade, it at least achieved something (like, voluntary, opt-in, gradual upgrading, without breaking compatibility) after paying such price.

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

For example there were no SegWit when BIP39 came out

Maybe the BRD (Bread) wallet is the better example than SegWit to support your argument? I didn't watch through such history, but git commit date etc indicates that BRD had adopted BIP39 before BIP44 came out. Then BRD keep using such "nonstandard" path up till now.

However, just like what I've outlined in my previous post, such case is not bad, a user can still manually specify (or something better, like what Electrum had recently done, to automatically probe/scan) such nonstandard path.

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

and users can create both legacy and SegWit wallets from the same mnemonic

That's exactly the nice advantage of BIP39, with BIP44/49/89 compliance. So smooth, so convenient, without re-creating a brand new wallet, and then redoing the boring backup job for it.

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

but while recovering they have to explicitly tell the wallet their address type or could end up with a wrong set of addresses.

To be frank, that's exactly the discrimination (mentioned in my previous post) put on BIP39 by Electrum devs, who obviously dislike BIP39 very much. However I would still appreciate them, because at least they worked hard to provide basic support for BIP39/44/49/84, albeit they insist on putting such scary/annoying warnings/discrimination on BIP39 wallets.

I also respect their decision to not provide those 3 address types (1/3/bc1, or P2PKH/P2SH-P2WPKH/P22PKH) in one same wallet - although I really think such decision sacrifices convenience/usability for code simplicity/maintainability etc, which doesn't seem worthwhile.

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

The alternative algorithms are each addressing different features that are lacking from BIP39 in their own way. For instance Electrum makes it flexible so that the algorithm can accept any wordlist of any number of words instead of the fixed 2048 ones BIP39 uses.

Just like my post above, I think I know how Electrum 2.0 seed achieve its amazing feature of validating a seed phrase without knowing the word list. However such trick doesn't seem to be so necessary, although it seems to be cool - although I see the fact that vanity mining on seed can introduce some lags during seed generation, I don't think it's a fatal problem either, I honestly still think it's cool.

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

Quote

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.

Good point but still having it is better than not having it.

I tend to agree with you - however the lack of version/type bits can also be justified with simplicity: it's a seed, nothing more. Just like the case of yprv/zprv, I appreciate the newly designed "output descriptors", which is intended to take over the job previously handled by yprv/zprv. There's also criticism on yprv/zprv because yprv/zprv is "violation of layering". What's more, no matter whether BIP39 looks ugly, after all it works, countless users have been relying on it. I don't think disturbing existing users good, especially when there's no much sigificant gain (like new features such as Shamir's Secret Sharing etc).

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

Besides you can still override the default behavior and derive any key at any path you like.

This can be used to nitpick "BIP39-killers" like Electrum 2.0, aezeed etc as well.

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

I was talking about the words used in the word list and the inconsistency that exists for the rules required to choose a word. For example you shouldn't use words that are similar (aim, air) but some words lists like English do.

There are better examples supporting your argument, like: "arm" vs "armed", "mix" vs "mixed". Besides, I think it's really not good for the simplified Chinese word (character) list to lack sorting according to pronunciation/pinyin.

However, I still want to repeat my opinion that such imperfections are not fatal, so that it doesn't seem worthwhile to try to "kill BIP39" - let alone the fact that BIP39 can't be killed, up till now at least.

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

Quote from: pseudo_geek on December 06, 2020, 04:36:19 PM

Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list?

It does need to know the wordlist but it doesn't force you to use 2048 words in your list, you can have 10000 words for example or 3!

To my understanding, the beauty of Electrum 2.0 seed is that, a wallet which doesn't generate new Electrum 2.0 seeds (in other words, being able to import existing Electrum 2.0 seeds) don't need to know (hard-code, download) the word list at all, just hashing (and the tiny bit of knowledge of defined version bits) is already enough.

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

Quote

That explains why Electrum wallet GUI often seems to lose responding for several seconds during generating new seed - because it's still busy finding the required vanity seed for you.

What you are explaining is not about the word list but the algorithm used and it is a very fast one since it is simply computing a handful of HMACSHA512 hashes that is quite fast and should not slow down the UI at all.
If you are experiencing a slow speed it may be due to generation of all the child keys from that seed.

I don't think losing responding for merely several seconds during a one-time job like seed generation is a significant problem - actually I think it's almostly negligible. However to my understanding it's indeedly caused by vanity mining. which also explains why sometimes it doesn't seem to lag at all, and sometimes it lags for some more seconds.

Also, obviously such vanity mining doesn't have much to do with word list - I never said it either.