1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
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 <pw@vps7135.xlshosting.net>) 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 <pieter.wuille@gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
|
