On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.

Well, as we're the first pioneers of bip32, let's start using it in some sane way and I'm sure the others will join. Just because they don't want to incompatible software.

Actually I quite like that you're not wasting bip32 space by using some dynamic allocatons in higher address space, so I'm happy to follow your rules and I think we can agree on generic discover algorithm which maybe won't be optimal, but will find all used addresses and won't need any additional information directly in mnemonic.

As I wrote in previous post, in worst case I can imagine dropdown list on import dialog, which will ask user which software has been handling the seed before, to speedup the scan. But for now I don't see this necessary at all.

Also, I can imagine that bip32 itself might be superseeded in the future.


Although I can imagine that as well, I hope that it won't be the case. We need to unite and integrate instead of making incompatible applications.

One disadvantage of bip32 is that in fact it is too much flexible, so we even falled into the necessity of defining version of discovery algorithm. Lets set up best practices how to use it and other will follow instead of creating zillion cross-incompatible algorithms which won't understand each to other.
 
The other question we might be solving is strenghtening (your proposal).
I consider
that this is not a strong requirement for Electrum, because it does not
let the user
choose their seed phrase. However, if a few bits of the seed phrase are

Hardening and password protection are two unrelated requirements. Again, there are some scenarios in which use can leak part of the mnemonic to attacker, so hardening prevent to bruteforce the rest information by attacker, even if the mnemonic isn't passphrase protected.

I'm especially refering to our algorithm of mnemonic import to Trezor during disaster recovery (when Trezor is destroyed and user wants to import the seed to another one), so that leak isn't just a theoretical concept, but real-word scenario.
 
allocated 
for metadata, then I guess strenghtening can be part of it. That's
another good
reason to have a version number encapsulated in the seed.

Actually creating optional features of such algorithm only make things complicated (and less cross-compatible). Every software still needs to implement such hardening even if it is optional feature, to be compatible with other clients. Then I don't see any reason why to have it optional.
 
Don't forget that the proposal uses only 4 bits of version, which isn't too much combination for all these optional features ;-).

I too wonder why the transformation needs to be bidirectional in bip39.


Well, I wrote longer answer in previous  email. tl;dr; there's quite easy way how to make the algorithm bi-directional, so I don't see a necessity to drop potentially useful feature for no good reason.

I was thinking about your proposal and I realized that both our solutions solves a bit different problem. Lets summarize features (and forget to wordlist fights for moment):

bip39:
+ bi-directional
+ passphrase protected
+ shorter mnemonic or shorter wordlist
- predefined wordlist

ThomasV proposal:
+ any software can has its own preferred worlist
? passphrase protected
- one-direction only
- longer mnemonic or longer wordlist

Back to wordlist fights
a) actually I think that the wordlist choice is far less important than it may look at first glance. Thomas thinks that bip39 wordlist is disaster, me and many other thinks it is ok, but mainly that it is very subjective.

b) I see the beauty of "custom wordlists" in Thomas proposal, still if it means the algorithm is uni-direction only, it is very strong disadvantage to our usecase.

c) I advocated our wordlist mainly because we put a lot of effort into it and after many weeks of tuning it is already done; not because I think that one method of picking the words is superior to other. I mean - if Thomas can offer any other plain-english wordlist which he'll be happy with, I'll vote for dropping our own wordlist and to use Thomas's version for the deal that he'll accept our need for bi-directionality and he agrees on the rest of bip39 ;-).

Marek