Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Uh4IZ-0002Xx-6X for bitcoin-development@lists.sourceforge.net; Mon, 27 May 2013 20:45:43 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Uh4IT-0004nC-6s for bitcoin-development@lists.sourceforge.net; Mon, 27 May 2013 20:45:43 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id EDCEB33D140; Mon, 27 May 2013 22:45:30 +0200 (CEST) Date: Mon, 27 May 2013 22:45:30 +0200 From: Pieter Wuille To: Michael Gronager Message-ID: <20130527204529.GA10743@vps7135.xlshosting.net> References: <51A32A30.8040504@ceptacle.com> <51A35B2C.7060802@ceptacle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A35B2C.7060802@ceptacle.com> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.1 (/) 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 (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1Uh4IT-0004nC-6s Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP0032 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: Mon, 27 May 2013 20:45:43 -0000 On Mon, May 27, 2013 at 03:10:04PM +0200, Michael Gronager wrote: > Commenting on my own mail... > > Rereading the BIP, it occurs to me that the private derivation is > actually intentional. So: > (m/i/j/k)*G = (M/i/j/k), but (m/i'/j/k)*G <> (M/i/j/k) (M/i'/j/k => ERROR) > > But: ((m/i')*G)/j/k = (m/i'/j/k)*G > > So, the motivation for the private derivation is to avoid the known (K, > c) and known k_i => k known too! I fear that many will fall in this > trap, though... I think the current formulation in the BIP text is a bit confusing, as there is both "public derivation" (namely: derivation that can be done using just the public key), and the "public derivation function" (the one that takes the public key as input). Any suggestion for better terminology is welcome. One possibility is calling it type-1 and type-2 derivation, but that's only enlightening if you of the origin of the concept. There is current "test vector generation" code on the 'detwallet' branch on my github repo, but this isn't useful for actual deterministic wallets. I'm working on having an implementation that nicely integrates with the key abstraction. Also, there are already other implementations available, such as this Python one https://github.com/FelixWeis/hdwallet, and Java code in Bits of Proof (with whom the test vectors match, after finding a bug in mine...) Of course, implementing a determinstic wallet is more than just key derivation. There is dealing with detecting new keys/chains being used, lookahead, how to use accounts (if at all), and internal/external subchains. I think this is much more likely to differ more between different implementations, and perhaps interesting applications -- Pieter