Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VbphU-0005m6-6D for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 10:42:04 +0000 X-ACL-Warn: Received: from mail-vc0-f176.google.com ([209.85.220.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VbphS-0003bf-P3 for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 10:42:04 +0000 Received: by mail-vc0-f176.google.com with SMTP id ia6so1790888vcb.21 for ; Thu, 31 Oct 2013 03:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=QBAmTdvKX6TFLiQBg6wsO6aBJuYxoM3MBTSkcdqLwFU=; b=FW2eKI1TODiuX4MTNAXOfNkRcjp21w/4C2B0gTQ40E9cIKBA5Jf1pnIRiU31B7c20n s22a89SJBl27v7qF08FPHWl8SSLqfGvE+kwpUnITfNNwQUTkXadbPxJTAjQlC88fx6F5 BzVLzy1jljXYO2djhl2UICOcyY+wSK6IqdKw+s+hvqj5rhJK3mhMxO0MqKiA1Ojg+1+p ckR1woTjlwtYtG13sfClD4LWpthWFnF/Nm9Yfmguw0smgkTIxMOTeaYqmhVgNuZrYell Cc6d5IPBsIuCnuGC9bR64U0a51Xuh7zCmLpEg/Ag/0B2osdeo7gaZJKzPF5sjqVBwtDg 0iQA== X-Gm-Message-State: ALoCoQnKxqLkQ+7x5gaZMbCuLqbGJOCf8zwpclxQjcgd5ijaNt+1epXlyJ6K8f+ckF/RtbqHT3cK X-Received: by 10.58.180.227 with SMTP id dr3mr1385542vec.36.1383216117120; Thu, 31 Oct 2013 03:41:57 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.59.1.2 with HTTP; Thu, 31 Oct 2013 03:41:27 -0700 (PDT) In-Reply-To: <52721F47.30206@gmx.de> References: <526BDEC2.2090709@gmx.de> <52721F47.30206@gmx.de> From: slush Date: Thu, 31 Oct 2013 11:41:27 +0100 X-Google-Sender-Auth: 9zyxGkMlkzki0LFSFwbds6E3MDI Message-ID: To: Thomas Voegtlin Content-Type: multipart/alternative; boundary=047d7b66fbcf4f25a804ea071943 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1VbphS-0003bf-P3 Cc: "bitcoin-development@lists.sourceforge.net" 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 10:42:04 -0000 --047d7b66fbcf4f25a804ea071943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Strange, I didn't receive the response from sipa in separate message, so I'll respond to him at first place. Le 26/10/2013 23:30, Pieter Wuille a =E9crit : > 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, t= o > decrease the impact of worst-case situations. Agree (hardening is default in bip39). Marek --047d7b66fbcf4f25a804ea071943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Strange, I didn't receive the response from sipa in se= parate message, so I'll respond to him at first place.

Le 26/10/2013 23:30, Pie= ter Wuille a =E9crit :
> I'm not sure whether we're ready to standardize on something l= ike that
> yet, not having established best practices regarding diffe= rent wallet
> structures. I do think we first need to see what possib= ilities and
> developments are possible related to it.

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

So if I mig= rate 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 d= imensions (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 chea= p, but this discovery needs to be done only during the import.

For the rea= son that I think this is the only sane algorithm of general use of bip32 sp= ace, I still don't see why we do need some extra metadata. I would unde= rstand this if Electrum will use for some strange reason addresses in highe= r 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 o= f Electrum, there is a strong reason to want this
> encapsulated toge= ther 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 sp= ace using some gap factor (actually I think "5" is too low by def= ault) 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 stat= ement "no metadata in mnemonic".

> = Regarding other requirements, I wonder why we want the transformation
&g= t; 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',

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

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

To limit the complexity of such algorithm it is better to produce plain se= ed (128, 192 or 256 bits, depends on settings) and then transform the resul= t of such "deterministic seed" to mnemonic, so for us the bi-dire= ctionality is quite strong requirement. *Maybe* it would be possible to com= bine 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 c= lear and simple as possible, especially while handling with seed generation= .

> = I would=A0strongly prefer if it had at least some strengthening built-in, t= o
> decrease the impact of worst-case situations.

Agree (hardening is default in bip39).


Marek
--047d7b66fbcf4f25a804ea071943--