public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP0032
Date: Mon, 27 May 2013 22:45:30 +0200	[thread overview]
Message-ID: <20130527204529.GA10743@vps7135.xlshosting.net> (raw)
In-Reply-To: <51A35B2C.7060802@ceptacle.com>

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




  parent reply	other threads:[~2013-05-27 20:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27  9:41 [Bitcoin-development] BIP0032 Michael Gronager
2013-05-27 13:10 ` Michael Gronager
2013-05-27 13:39   ` Michael Gronager
2013-05-27 17:21     ` Amir Taaki
2013-05-27 20:45   ` Pieter Wuille [this message]
2013-05-28  5:16 Tamas Blummer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130527204529.GA10743@vps7135.xlshosting.net \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gronager@ceptacle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox