Let's first try to agree on what we are solving.
It seems that Thomas wants - in addition to the cryptographic data -
to encode the tree structure, or at least version information about
what features are used in it, inside the seed.
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.
In addition, information about the wallet structure is strictly less
secret than the key data - it is even less confidential than address
book data, transaction annotations, labels and comments and
bookkeeping information. It could be backed up anywhere and everywhere
without any repercussions, as far as I can see. 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.
(if really needed, any key derivation scheme that starts from random
strings can be augmented with metadata by enforcing property-bits on a
hash of the string (so not of the output), as this data doesn't need
protection from brute-forcing).
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', I would
strongly prefer if it had at least some strengthening built-in, to
decrease the impact of worst-case situations.
If the reason is backward-compatibility, I think that any client that
supports seeds already can just keep supporting whatever they
supported before. Only if it matches both encoding schemes (as
mentioned before) there is a potential collision (and in that case,
the user could just be asked).
--
Pieter
On Sat, Oct 26, 2013 at 10:47 PM, slush sl...@centrum.cz wrote:
Hi Thomas,
can you more elaborate on that version bits? What is exact meaning of it?
I still think this is more an implementation problem. What stops Electrum to
do the same algorithm for searching branches as it is now for used
addresses?
These version bits need to be covered by the specification as well,
because if any client will use them differently (or won't use them at all),
it will break cross-compatibility between clients, which was another goal of
bip39.
Marek
On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin thoma...@gmx.de wrote:
here is a simple implementation, with some ideas on how to format the
metadata:
https://en.bitcoin.it/wiki/Talk:BIP_0039
--
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=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
