Update BIP32: 'hardened' terminology + explicit conversions

sipa commented at 11:47 pm on January 25, 2014: member

sipa commented at 11:49 pm on January 25, 2014: member

@mikehearn Please have a look!

This is a significant rewrite; it’s probably better to look at the formatted result (https://github.com/sipa/bips/blob/bip32update/bip-0032.mediawiki) than at the diff.

sipa commented at 3:17 am on January 26, 2014: member

Request for comments:

Are the explicit conversion functions (serpoint, ser32, ser256, parse256) useful, or do they clutter?
Same for the N() (neuter) function: useful to explicitly make derivation chains private or public?
Is using a function (point(k)) an improvement over writing k*G (making it clear that it’s sort of a conversion, but I’m not entirely happy with the name “point”).
Notation for hardened keys: is the suffix “h” better than just “’”? It’s sort of ugly when preceded by a variable.
Shorter function names, or are these long ones more readable?

mikehearn commented at 5:38 pm on January 26, 2014: contributor

I think this is a huge improvement, thanks! Just a couple of very minor things:

changelog at the top could be updated
There’s a Java impl in bitcoinj as well (code.google.com/p/bitcoinj)

Update BIP32: 'hardened' terminology + explicit conversions 6a418689f3

in bip-0032.mediawiki: in 6a418689f3

189@@ -170,63 +190,66 @@ In addition to the expectations from the EC public-key cryptography itself:
190 * Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2<sup>128</sup> group operations).
191 the intended security properties of this standard are:
192 * Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
193-* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
194+* Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
195 Note however that the following properties does not exist:

laanwj commented at 2:35 pm on January 27, 2014:

does not -> do not

in bip-0032.mediawiki: in 6a418689f3

162@@ -143,22 +163,22 @@ Each account is composed of two keypair chains: an internal and an external one.
163 
164 In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain.

laanwj commented at 2:43 pm on January 27, 2014:

This doesn’t mention that coordination is needed to prevent the two systems from stepping on each other’s toes (dealing out the same keys by generating overlapping indices). Does it assume that they will be using different accounts?

laanwj commented at 2:50 pm on January 27, 2014: member

I like the explicit conversion functions, especially as they are described in detail in an initial conventions section, this makes the document more accessible. The longer names are also easy to look up when needed. They don’t appear to cause clutter anywhere.

in bip-0032.mediawiki: in 6a418689f3

155-Each account is composed of two keypair chains: an internal and an external one. The external [[keychain]] is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.
156+An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account.
157 
158- * m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.
159- * m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.
160+Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.

laanwj commented at 2:52 pm on January 27, 2014:

No motivation is given for having separate internal/external chains. I suppose this is because they have different look-ahead properties (as mentioned later under wallet sharing) but it may be useful to mention this here.

sipa commented at 4:20 pm on March 12, 2014:

I’ll address this in a separate change.

sarchar commented at 11:32 am on January 30, 2014: contributor

Notation for hardened keys: is the suffix “h” better than just “’”? It’s sort of ugly when preceded by a variable.

My only concern is that for my site (http://bip32.org/), the subscripted “h” can’t (easily?) be typed into the custom derivation path. I don’t know how big of a concern that is because 99% of users will never see a derivation path, but at least for my site I won’t be able to support the “h” in custom paths.

sipa commented at 11:48 am on January 30, 2014: member

@sarchar How about a non-subscripted h?

Given that the other usage of ’ has been removed, I can just revert to using it for hardened derivation steps. Maybe others already depend on that notation too.

sarchar commented at 11:51 am on January 30, 2014: contributor

Would a non-subscripted h make it look like a hex number?

How about a plus sign?

laanwj commented at 7:57 am on February 10, 2014: member

@sipa is this ready for merging or are you still planning to update it?

sipa commented at 4:23 pm on March 12, 2014: member

I’ve added a note that the old notation (i’) is also allowed, in addition to i_H.

sipa referenced this in commit 6145e1ee1c on Mar 13, 2014

sipa merged this on Mar 13, 2014

sipa closed this on Mar 13, 2014

luke-jr referenced this in commit d8ec771caf on Mar 17, 2016

luke-jr referenced this in commit 5e40cf2455 on Jun 6, 2017

real-or-random referenced this in commit 7511d17864 on Nov 5, 2018

Update BIP32: ‘hardened’ terminology + explicit conversions #12