Le 26/10/2013 23:30, Pieter Wuille a écrit :
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.

Although many strange practices how to use whole bip32 space are possible, I think that we may (should?) agree on some "good enough" way how to discover already used addresses in bip32 space. I read Electrum sources about bip32 and I see that Electrum still uses quite flat structure (fixed amount of branches, indexes from 0 to n), which is of course very sane way.

So if I migrate seed to another (non-Electrum) software, I only need to discover close neighbourhood of the path "0", similarly like Electrum is doing with "gap limit" in plain old Electrum algorithm, except in two dimensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1, ...5/5 for gap limit "5"). I don't say such operation is cheap, but this discovery needs to be done only during the import.

For the reason that I think this is the only sane algorithm of general use of bip32 space, I still don't see why we do need some extra metadata. I would understand this if Electrum will use for some strange reason addresses in higher address space like 2^32-1 or so, but this is not going to happen at least in Electrum.

> I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.

Well, I can imagine that the bip32 compatible software will do full scan of address space using some gap factor (actually I think "5" is too low by default) or it can ask for wallet metadata like which software used such tree before, to speedup scanning process.

I see that Thomas wants to make this automatic and hidden to user and generally I agree that hiding the compexity to user is a good practice, but actually this particular situation sounds to me as an exact oposite of original statement "no metadata in mnemonic".

> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets',

ECDSA has one very nice option - (almost) any random data can be used as a private key. There are very nice schemas possible by using this feature and requiring private key to be specially crafted just because the user wanted to use mnemonic schema is very strong limitation to me.

To be specific, we (in cooperation with / inspired by Timo Hanke) developed method how to prove that the seed generated by Trezor has been created using combination of computer-provided entropy and device-provided entropy, without leaking full private information to other computer, just because we want Trezor to be blackbox-testable and fully deterministic (seed generation is currently the only operation which uses any source of RNG).

To limit the complexity of such algorithm it is better to produce plain seed (128, 192 or 256 bits, depends on settings) and then transform the result of such "deterministic seed" to mnemonic, so for us the bi-directionality is quite strong requirement. *Maybe* it would be possible to combine such algorithm and one-way mnemonic together, but it would complicate the design and I'm sure you understand that we want to keep things as clear and simple as possible, especially while handling with seed generation.

> I would strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.