Update BIP32: 'hardened' terminology + explicit conversions #12
Conversation
|
@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. |
|
Request for comments:
|
|
I think this is a huge improvement, thanks! Just a couple of very minor things:
|
| @@ -170,63 +190,66 @@ In addition to the expectations from the EC public-key cryptography itself: | |||
| * 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). | |||
| the intended security properties of this standard are: | |||
| * 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. | |||
| * 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. | |||
| * 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. | |||
| Note however that the following properties does not exist: | |||
|
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. |
|
|
||
| * 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. | ||
| * 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. | ||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'll address this in a separate change.
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. |
|
@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. |
|
Would a non-subscripted h make it look like a hex number? How about a plus sign? |
|
@sipa is this ready for merging or are you still planning to update it? |
|
I've added a note that the old notation (i') is also allowed, in addition to i_H. |
Update BIP32: 'hardened' terminology + explicit conversions
Renamed to BIP75, added extensions to BIP70 payment details
minor: close_signature -> closing_signed
Improve readability of Python implementation
No description provided.