BIP39 lookup table for paranoids

[pseudo_geek]

https://imgur.com/a/EX4PYpp

This is a BIP39 lookup table for paranoids. Use this with Ian Coleman's browser-based BIP39 tool ( https://github.com/iancoleman/bip39/releases ) . This tool helps you cross-check whether the mnemonic phrase matches the random number generated by coin tossing (note: never pick your random number subjectively, otherwise the entropy would be decreased), and whether the receiving addresses match with the hardware wallet. Using this off-line is strongly recommended.

It can't do anything other than that. It can't make you immune from backdoored wallet, hardware or software. You still have to make sure your wallet app or hardware is untampered, and make sure it's running in a trustworthy, clean and private environment.

The red line represents the 1st coin tossing result, 0 is for back and 1 is for front. Then the orange, yellow, green, blue, purple lines represent the 2nd, 3rd, 4th, 5th, 6th coin tossing results respectively.

Toss a coin for 5 times to find out which line/row the word lies, then toss for 6 times to find out which column. See, 11 times of coin tossing generates entropy of 11 bits, which uniquely represents a word, since BIP39 wordlist has exactly 2048 (2^11) words.
Therefore, tossing a coin for 128 times generates a 12-word mnemonic, while tossing a coin for 256 times generates a 24-word mnemonic.
Wait, 12*11=132 (24*11=264), where's the trailing 4 bits (8bits)? Oh, it's the checksum decided by the 128 (256) bits of raw entropy. As a human you can hardly know it without an electronic calculating device, however this doesn't matter. You can still know the range of the last word.

Only seeing leading 4 letters of each word? There's no problem, BIP39 was designed in the way that only leading 4 letters can already uniquely represent a word.

[1715505931]

1715505931

[1715505931]

1715505931

[o_e_l_e_o]

That's certainly a unique way of converting coin flips to a seed phrase, but I really don't like the way it is laid out. Once you get down to the green/blue/purple lines, it becomes far too easy to make a mistake. If you are following the table in real time as you work along 11 flips, it also becomes easy to forget your place.

Further, if you are going to create the full seed yourself, then you need to calculate the checksum yourself, so you still need the 128 or 256 bits in binary to plug in to a SHA256 function. My method has always been to simply write down 0 for heads and 1 for tails (or vice versa), convert each 11 bits to decimal, and then map to the word list direct from GitHub (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt). You don't risk the mistake of losing your place, you have everything written down so you can double check it, and you can easily use the number to calculate the checksum.

[pseudo_geek]

convert each 11 bits to decimal

That's actually the sole purpose of this table. A human can do this without any electronic device or calculation skills.

it also becomes easy to forget your place

Maybe it's not that awkward. It's actually a process to narrow down the range.

it becomes far too easy to make a mistake

Then it doesn't really matter. A human (almostly) cannot calculate the checksum bits without electronic device. This table only helps a paranoid to cross-check, not generating.

[o_e_l_e_o]

That's actually the sole purpose of this table. A human can do this without any electronic device or calculation skills.

That's kind of my point. I can do it quicker with less chance of making an error by thinking of 11001011101 (for example) as 1024 + 512 + 64 + 16 + 8 + 4 + 1, than I can by working out "below the red line, below the orange line, above the yellow line, above the green line, below the blue line, left of the red line, right of the orange line, right of yellow line, right of green line, left of blue line, right of the purple line."

Then it doesn't really matter. A human (almostly) cannot calculate the checksum bits without electronic device. This table only helps a paranoid to cross-check, not generating.

This is true, but provided you have written down your coin tosses as I said above, you can use an open source SHA256 implementation on an airgapped device to calculate the necessary 4 or 8 bits and then work out the checksum word yourself, which is superior to trusting your wallet software.

[pseudo_geek]

I can do it quicker with less chance of making an error by thinking of 11001011101 (for example) as 1024 + 512 + 64 + 16 + 8 + 4 + 1

Yeah, it's nice for different people to have different preferences.

"below the red line, below the orange line, above the yellow line, above the green line, below the blue line, left of the red line, right of the orange line, right of yellow line, right of green line, left of blue line, right of the purple line."

In my opinion, the point of making a table or a diagram is to illustrate something that's not easy to describe with words.

To me it's actually "find out which line the word lies, then find out the column in that line". Also, it's not only "above/below/left of/right of" a colored line (which really sounds confusing), I've already said it's a process of narrowing down the range. Each line would further shrink the range by half.

you can use an open source SHA256 implementation on an airgapped device to calculate the necessary 4 or 8 bits and then work out the checksum word yourself, ....

The last 4 or 8 bits doesn't really matter. It's meaningless for an attacker to manipulate it. Even if it's manipulated, it costs almost nothing to scan through all the 2^4 or 2^8 possible "mnemonics with valid or mismatched checksum".

... which is superior to trusting your wallet software.

According to my understanding, this lookup table helps cross-checking in two cases:

(1) An open-source mnemonic-processing software like Ian Coleman's BIP39 tool still requires an entropy source, which could be suspicious to paranoids - then this lookup table can eliminate the possibility/risk of rigged/flawed random generator.

(2) A backdoored wallet software (or firmware of a hardware wallet) can display attacker-controlled receiving addresses which are unrelated to the mnemonic phrase at all - then a paranoid can compare addresses displayed by the wallet and the mnemonic-processing software. In this case the lookup table doesn't really participate, however without the above first step this might not be meaningful.

However to my best knowledge such cross-checking can't provide absolute security. One of the possible reasons is that ECDSA has an inherent side-channel infoleak issue that a maliciously manipulated k-value can generate a signature which stealthily leaks secret data to the attacker.

[pseudo_geek]

If I set the reverse problem for myself, i.e. to find the random number that "correspond" to SEED I have, it could be revealed with use of that table , couldn't it?  If that's true would be nice to have automated mode for such table which in the long run means the software development .

I'm not sure what did you mean. If you worried about potential info leak by moving mouse pointer on this image, I think it should be better to print out this lookup table, so that no electronic device would be required at all... (although this is true only for cross-checking purposes)

[webtricks]

Is this your original work? Impressive!

Further, if you are going to create the full seed yourself, then you need to calculate the checksum yourself, so you still need the 128 or 256 bits in binary to plug in to a SHA256 function. My method has always been to simply write down 0 for heads and 1 for tails (or vice versa), convert each 11 bits to decimal, and then map to the word list direct from GitHub (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt). You don't risk the mistake of losing your place, you have everything written down so you can double check it, and you can easily use the number to calculate the checksum.

Sure thing! There are better ways in which entropy could be created off-system and then used with precision in system but OP's solution is unique. It's far from perfect and I doubt anybody will use it for production but still I admire unique thinking and that's why I merited the thread.

[pseudo_geek]

Is this your original work?

Yes. But I think such idea should not be so fresh.

I posted this table on another forum first.

[pooya87]

then map to the word list direct from GitHub (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt).

extreme care must be taken when things are done manually, specifically in this case because converting the entropy (coin flips) to mnemonic is done based on index of each word and the numbers beside each word on github is the line number.
in other words when you get 1 (00000000001) then your word is "ability" and NOT "abandon".
if the line numbers are used the end result will not be the same as what a BIP39 tool would generate from the same entropy and also you will be using a 2047 word long list instead of 2048 since you'll be deleting the last word (2048=zoo).

[TheDigitalMan]

I was going to start a new thread but this is EXACTLY what I was wanting to discuss!

The word list that this thread refers to should be numbered 0 thru 2047.  Correct? 

That is why you say 1 would actually refer to ABILITY rather then ABANDON.

I am working on a project that will involve a printed copy of this mnemonic word list.  And I was thinking the numbering should be offset by 1 so that it was numbered beginning with ZERO and ending with 2047 = zoo.

Can anyone confirm this?  I'm doing final proofing on my project and I started scratching my head over the numbering.  Because I originally just took a copy of the word list and used it verbatim.  But I'm realizing it is numbered incorrectly.

I'm already 99.9 percent certain that I need to go back and revise my numbering but just wondered if anyone else had any opinions?

I DO want the number associated with the word to match up with the number being used by the BIP39 protocol when creating the addresses etc.  I understand the last word is a checksum in the mnemonic word list etc.  But I still think "Abandon" should be numbered 0 and not 1.  I'm not wrong in my thinking on this am I?  I'm surprised the word list got published like it did... but I guess their thinking was, it was a list of 2048 words and they numbered them accordingly.

Thanks for reading and any feed back you might have.  I'd like this printed list to be numbered in the appropriate manner and even though the list on github is numbered 1-2048 I'm thinking I should number mine 0-2047.

Kresp.

[NotATether]

Only seeing leading 4 letters of each word? There's no problem, BIP39 was designed in the way that only leading 4 letters can already uniquely represent a word.

This is not correct. As someone who's busy developing a BIP39 checker, this is only a recommended guideline. It is not strictly required to make every word have 4 unique leading letters, but it's highly discouraged not to because the more characters you need to iterate in a word to tell it apart from other words, the more likely someone's going to type the wrong word in their seed phrase.

It is definitely possible to create and use a wordlist that breaks this rule, but such a wordlist has no chance of getting merged into the BIP39's official github repository.

The word list that this thread refers to should be numbered 0 thru 2047.  Correct?

If you're just printing out a list of words, it shouldn't matter how you number your words as long as you do it consistently in your project. If this is supposed to be fed into a machine, 0-based numbering, the number can be directly converted to a binary value. But if it's supposed to be read by humans, we find it a lot less confusing to remember numbers of words if the words use 1-based numbering.

[o_e_l_e_o]

And I was thinking the numbering should be offset by 1 so that it was numbered beginning with ZERO and ending with 2047 = zoo.

This is correct.

You first generate 256 bits of entropy, then use SHA256 to calculate and append the 8 bit checksum. You then split the resulting 264 bits in to 24 chunks of 11 bits each. These can range as follows:

Code:

00000000000
00000000001
00000000010
00000000011
00000000100
00000000101
00000000110
00000000111
00000001000
.....
11111111111

00000000000 converted to decimal is 0 - abandon.
11111111111 converted to decimal is 2047 - zoo.

I'm surprised the word list got published like it did... but I guess their thinking was, it was a list of 2048 words and they numbered them accordingly.

The wordlist (https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt) was published as a list of words without associated numbers. It is only numbered because GitHub uses line numbering starting from 1.

[TheDigitalMan]

Hey thanks!  I appreciate the confirmation.  And the extra information regarding how it works. Much appreciated!

[pseudo_geek]

This is not correct. As someone who's busy developing a BIP39 checker, this is only a recommended guideline. It is not strictly required to make every word have 4 unique leading letters, but it's highly discouraged not to because the more characters you need to iterate in a word to tell it apart from other words, the more likely someone's going to type the wrong word in their seed phrase.

It is definitely possible to create and use a wordlist that breaks this rule, but such a wordlist has no chance of getting merged into the BIP39's official github repository.

I'm aware. BIP39 requires the wordlist to check validity of a mnemonic phrase, which is one of many reasons why some people dislike BIP39. This can be viewed as a self-inconsistency of BIP39 spec, however I just think the fact that "wordlist flexibility" of BIP39 doesn't really work is not very important. Official English wordlist can work well, that's enough. In my opinion, the attempts to takeover BIP39 will only make the situation even worse, that the user (even machine) can't tell exact type of those 12 words at hand.

[pooya87]

I'm aware. BIP39 requires the wordlist to check validity of a mnemonic phrase, which is one of many reasons why some people dislike BIP39. This can be viewed as a self-inconsistency of BIP39 spec, however I just think the fact that "wordlist flexibility" of BIP39 doesn't really work is not very important. Official English wordlist can work well, that's enough. In my opinion, the attempts to takeover BIP39 will only make the situation even worse, that the user (even machine) can't tell exact type of those 12 words at hand.

people dislike BIP39 but "checking validity" is not one of them. there are lots of issues with this proposal that has made it not-desirable. for example the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing, recovery using mnemonic (which was supposed to be easy) becomes hard.
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.

[pseudo_geek]

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

No, it's not hard at all. With standard derivation paths (and corresponding script/address type) 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" (or something more modern, like "output descriptor") - 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. (Oh, if you insist on thinking deeper on this, a malicious "deep" "exotic" derivation path can be destructive as well, just like a maliciously tampered passphrase of BIP39 mnemonic - however I think this problem is probably avoidable by, like, providing a known list to the user - also, even if there's a "deep" "exotic" derivation path, it's still remembered by the wallet until deletion, while the passphrase would be forgotten by the wallet immediately)

Then 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 mnemonic phrase 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...

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 (which is still better than the status quo outlined above, sigh). 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 wants 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 (rather than better behavior of exporting/importing properly isolated child HD node xpub/xprv/output descriptors).

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. "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/reversible 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/reversibly 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).

[pseudo_geek]

There're also other things about Electrum 2.0 seed that I want to nitpick, like, if I'm not mistaken, Electrum wallet doesn't forbid using existing standard (single-signed) seed as a multi-sig cosigning key, and vice versa. Therefore, it's exactly the same problem of "only having the 12-word seed is still not enough", isn't it - if you enter a multi-sig seed as a standard (single-sig) one into Electrum, it will show you a blank wallet with 0 balance (typical symptom of "BIP39 derivation path syndrome"); if you forgot to take good care of such a dual-role seed, your co-signer/co-owner will probably blame you (because the co-owned funds might be stolen or permanently locked out).

Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list? The answer is: vanity mining. Electrum does vanity mining on its seed in order to embed their version bits into the seed phrase. 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.

[pooya87]

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

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...

You keep using the term "standard" while there is no such thing in bitcoin. 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.
In fact these differences are a good indication of existing flaws in mnemonic algorithms. (everyone is trying to address them in their own way).

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.

This problem is not particularly created by devs, it is introduced at a later time when new scripts were introduced to bitcoin. For example there were no SegWit when BIP39 came out and users can create both legacy and SegWit wallets from the same mnemonic but while recovering they have to explicitly tell the wallet their address type or could end up with a wrong set of addresses.
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.

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.

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.

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. Besides you can still override the default behavior and derive any key at any path you like.

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. "maybe just ignore it" - that's the blamed inconsistency of BIP39.

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.

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!

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.

[pseudo_geek]

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?

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).

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.

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.

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.

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 as well as redoing the boring backup job for it.

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/P2WPKH) in one same wallet - although I really think such decision sacrifices convenience/usability for code simplicity/maintainability etc, which doesn't seem worthwhile.

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.

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).

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.

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.

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.

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.

[NotATether]

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?

Yes those are better, a lot of BIPs have never made it to enforcement stage, which is what the word standard implies.


Once a BIP is published it becomes very hard to walk it back short of a major security vulnerability found in the design in which case they would theoretically release another BIP that deprecates the previous one, in fact that's sort of what happened to BIP39 (minus "major") if you read the comments on the github mediawiki page in the bips/ repo they wrote that they discourage its use. That's also what happened to the SSL 3.0 RFC after the POODLE attack was discovered, they published a new one that deprecated its use.

But you can't just obliterate a proposal from existence once its published in the internet because there is the risk that people have already made implementations based on it and deleting the proposal would invalidate those programs in the sense that it can't be proved anymore that they comply with the BIP based on official information.

It's the same reason RFC doesn't delete standards, Git hosting sites discourage you from overwriting remotes with a force push, and well-behaved programs do not reuse version bits that have been allocated for something else.

Meanwhile this is where alternatives to BIP39 have got us to: