Honestly I don't think BIP39 has fatal problems, although it indeedly has many imperfections. It doesn't seem to be the same case of something like POODLE attack - as long as you use SSL3.0, you are always vulnerable to such attacks; however just keep using BIP39 doesn't seem to introduce similar risks.

SSL/TLS session is transient thing. Therefore, it's less painful to migrate to upgrade/patched new protocol - although it's not completely painless, because there's many situations where installed old software can't be (easily) upgraded.


Agreed.

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?


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


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.


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.


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.


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.


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.


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.


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


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


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.


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.


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.

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.

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


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.



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

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.

How does vanity HDM (multi-sig) wallet generation works?

If you only know cosigner xpubs then where does the mnemonic come from?

If I feed this tool N xpubs, I will only get a N+1 of N+1 multi-sig setup, in which only the first address meets the vanity rules - did I get what you meant?

Also, are the pubkeys in a multi-sig setup sorted by default?

I think you may make this more clear in README, otherwise a noob like me will feel quite confused.

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

I posted this table on another forum first.

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 printed out this lookup table, so that no electronic device would be required at all... (although this is true only for cross-checking purposes)

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


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.


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


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

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


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


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.

Seems like P2WSH still not supported?

http://www.8btc.com/random-4
可以看看这篇。知道HD主公钥和任意一个子私钥，就可以算出HD主私钥，然后所有派生出来的私钥也都能算出来了。
密语其实就是主私钥。
不过问题在于丢失密语的情景下，可能主公钥也早就丢了，所以这个特性（或者说缺陷）往往没啥X用。

Defragmentation indeed improved the performance, but "manual preheating" still got much more significant effect...

Shouldn't the height of genesis block be zero?
If I type 0 on Blockcypher, it will return a error:
It seems that Blockcypher put the genesis block on height 1, thus makes the true block#1 inaccesible (unless specify sha256 directly: 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048).

Thanks. Just found that defragsvc was disabled unexpectedly.
(haha, someone encountered the same problem: [defragment-drives-dfrgui-exe-wont-start-after-1703-update from superuser - URL was automatically removed!? ] )
I've defraged my HDD, hope this will help.

OS: Win10 16299 x64
RAM: 16GB DDR3 1600 (dual channel)
CPU: Intel Core i7 4700MQ

My Bitcoin data dir is stored on my 5400rpm HDD. The OS is installed on 128GB SSD.
Though HDDs are expected to be slow, bitcoin-qt seems to be much more slower than my expectation.

Today, I was restarting bitcoin-qt full node on my PC, it showed that my node was 520 blocks behind the network. During the syncing process, taskmgr showed that HDD active time is 100%, but, the speed was EXTREMELY slow: validating one block seemed to take about one minute!

dbcache size was already set to 2048MB, which was not seemed to work.

Then, I tried some tricks to "boost" the syncing process:
1.Use procexp to suspend bitcoin-qt.exe;
2.Execute following command in cmd:
3.Wait for the command to complete (took me about 5min).
After that, my taskmgr showed that the "cached" RAM size increased significantly.
4.Use procexp to resume bitcoin-qt.exe;

Dramatic things then happened: bitcoin-qt was significantly "boosted up". Time consumed by validating each block has shrunk to only several seconds!

I wonder if I made any mistakes? Doing such "manual optimization" is so strange...

I found it quite strange while observing data at http://segwit.party/charts/#.
SegWit tx percentage was rising constantly since activation - until blocks around #491300, after that, the percentage dropped so sharply.
What happened at that time ?