From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VboK8-0005Vm-BY for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 09:13:52 +0000 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; Received: from mout.gmx.net ([212.227.17.21]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1VboK7-00017A-17 for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 09:13:52 +0000 Received: from [192.168.1.27] ([86.73.30.143]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MXZ4Q-1V7drq1b3m-00WShv for ; Thu, 31 Oct 2013 10:13:44 +0100 Message-ID: <52721F47.30206@gmx.de> Date: Thu, 31 Oct 2013 10:13:43 +0100 From: Thomas Voegtlin 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: <526BDEC2.2090709@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5OE17+39h4OP56YY4FyH2QRXFK7oOR3SBCz7C7jZnsjFui5n9oI Rq0hnKeOJ22hNHnC3uO6+yAK2c0peOIU4wARI6pIVS+Rl+umiPqg5q1pGOkPRgsdnWSLe/V BImPcEwZZVXO9K0iJazzZFk1ze0H0G0DXFF8vvFzIci0Ike2aadXbXEXcsj5dZA2ljxeK6+ vtE8w+4HQmYIMw0rXKt4w== X-Spam-Score: -1.2 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.21 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (thomasv1[at]gmx.de) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (thomasv1[at]gmx.de) X-Headers-End: 1VboK7-00017A-17 Subject: Re: [Bitcoin-development] Proposal to replace BIP0039 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 09:13:52 -0000 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). >