slush wrote : > Two years ago I proposed exactly this and you refused to add extra > information to mnemonic, because "it isn't necessary" and "it makes it > longer to mnemonization". What changed since then?
I was wrong, and I fully acknowledge it. My concern was that adding extra information would make the mnemonic longer than 12 words. In addition, you proposed to allocate these extra bits for a checksum, not for metadata. However, a checksum does not really add any information, because Electrum checks the existence of a wallet directly from the blockchain. So, my feeling at that time was that adding extra bits would increase the risks (a longer seed is harder to memorize, increases the probability of mistakes, etc), and did not bring any real benefit. However, you showed since then how to solve this by using a slightly longer dictionary, and I do like your solution, I find it absolutely brilliant. In addition, I realize now that metadata (ie a "version number") is crucially needed, for the reasons mentioned in my previous post. > Hm, what exactly do you need to store about wallet structure? I lived > in opinion that everything is able to recover using CKD function to > generate new addresses and blockchain lookups for their balances. BIP32 gives a lot of freedom to wallet developers: it does not specify which branches of the HD tree shall be used for which purpose. However, if you want to recover a wallet from its mnemonic (a requirement for Electrum), then you need to know which branches to explore. In Electrum 1.9 I had to make some choices about branch allocation. However, the decisions that I made are certainly not final, so it is important to be able to change them in the future. Thus, this metadata needs to be added to the mnemonic. > Yes, that's true. It isn't possible to make everybody 100% happy. At > least I wanted to be constructive and asked you to replace the most > problematic words. No pull request from you so far. The solution I propose is very different from BIP39, and it does not require to predefine a dictionary. My proposal is actually somewhat similar to Pieter Wuille's proposal, which I discovered after his recent post. ( https://bitcointalk.org/index.php?topic=102349.0 ) > Yes, it was original idea. So far I don't think this is a problem. Of > course some words may have some meaning across languages, but it > should be easy to avoid them. There are tens of thousands words in > every language and we need to pick "only" 2048 words to wordlist. > ... > Are your worries about overlapping words across languages a real issue? No, there are not so many words that are frequent enough. Overlapping will be an issue, especially if we go for a 4096 words dictionary. > If I understand this well, it is basically one-way algorithm "mnemonic > -> seed", right? Seed cannot be printed out as mnemonic, because > there's hashing involved, but the bi-directionality has been the > original requirement for such algorithm (at least in Electrum and bip39). You are right, this encoding is not symmetric. Bi-directionality has never been a requirement for Electrum. May I ask why you need bi-directionality in Trezor? (the only reason I can think of is if you want to export a bip32 branch into another wallet, but this would create a very long mnemonic string) > Then, how is this different to picking 12 random words from dictionary > and hashing them together? I don't see any benefit in that "mining" > part of the proposal (except that it is lowering the entropy for given > length of mnemonic). it makes it possible to hash a utf8 string, and to retrieve the metadata from the hash. Thus we don't need to spend ages arguing about the best choice of a dictionary, and to set it in stone. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoinemail@example.com https://lists.sourceforge.net/lists/listinfo/bitcoin-development