From b39b409c2668d90c851edeff468b2ac5fe2956d2 Mon Sep 17 00:00:00 2001 From: Dustin Dettmer Date: Wed, 5 Jun 2019 14:37:25 -0700 Subject: [PATCH] Add simpler explanations where I got confused originally reading this. Essentially I added the simple explanation for some things next to the more complex ones originally used. If I had these in there when I first came upon this document, I would have had a much easier time digesting it. Hopefully these changes help the next peson who reads it. --- bip-0032.mediawiki | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 18b3b0cb..e6a4ff4b 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -51,10 +51,11 @@ Addition (+) of two coordinate pair is defined as application of the EC group op Concatenation (||) is the operation of appending one byte sequence onto another. As standard conversion functions, we assume: -* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p. +* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p (similar to making public key). * ser32(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first. * ser256(p): serializes the integer p as a 32-byte sequence, most significant byte first. -* serP(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate. +* serP(P): serializes the coordinate pair P = (x,y) (aka. the public key) as a byte sequence using [https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L177 SEC1]'s compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate. +** [https://github.com/bitcoin-core/secp256k1 Libsecp256k1]'s pubkey_serialize and pubkey_parse functions implement this format. * parse256(p): interprets a 32-byte sequence as a 256-bit number, most significant byte first. @@ -64,6 +65,8 @@ In what follows, we will define a function that derives a number of child keys f We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code. +When deriving child keys, a 'hardened' child key can only be generated using a private key. This provides security advantages and prevents adversarial public key tracing. It is typically used to separate 'accounts' from one another. + Each extended key has 231 normal child keys, and 231 hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 231-1. The hardened child keys use indices 231 through 232-1. To ease notation for hardened key indices, a number iH represents i+231. ===Child key derivation (CKD) functions=== @@ -105,6 +108,8 @@ To compute the public child key of a parent private key: * CKDpub(N(kpar, cpar), i) (works only for non-hardened child keys). The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information. +The non-hardened result is typically used by a server to continually generate receive addresses without the ability to spend funds. + ====Public parent key → private child key==== This is not possible.