Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
	designates 212.227.17.21 as permitted sender)
	client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
	helo=mout.gmx.net; 
Message-ID: <52721F47.30206@gmx.de>
Date: Thu, 31 Oct 2013 10:13:43 +0100
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>	<CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com>	<526BDEC2.2090709@gmx.de>	<CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
	<CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
In-Reply-To: <CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
Precedence: list

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.
Also, I can imagine that bip32 itself might be superseeded in the future.

I understand that encapsulating a version number in the seed phrase might
not be as important for other wallets as it is for Electrum. So it is 
probably not
necessary to propose another BIP for that. I will simply implement it 
for Electrum,
and I will try to do it in such a way that other wallets can use the 
same format.

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

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


Le 26/10/2013 23:30, Pieter Wuille a écrit :
> 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).
>