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.
64 | @@ -64,6 +65,8 @@ In what follows, we will define a function that derives a number of child keys f 65 | 66 | 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. 67 | 68 | +When deriving child keys, a 'hardened' child key can only be generated using a private key. This provides security advantages but reduces the usefulness of HD key derivation. It is typically used to seperate 'accounts' from each other.
When deriving child keys, a 'hardened' child key can only be generated using a private key. This provides security advantages but reduces the usefulness of HD key derivation. It is typically used to separate 'accounts' from each other.
50 | @@ -51,10 +51,11 @@ Addition (+) of two coordinate pair is defined as application of the EC group op 51 | Concatenation (||) is the operation of appending one byte sequence onto another. 52 | 53 | As standard conversion functions, we assume: 54 | -* 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. 55 | +* point(p): returns the public key for p. This is the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p.
I find this to be somewhat cyclic. We define public/private keys in function of this operation (i.e., the corresponding public key to private key p is point(p)). The change here is adding the reverse that (i.e., defining point(p) as the public key to p).
Yeah I'm in agreement with @sipa here. Points are used as public keys but aren't equivalent to them in certain use contexts.
How about this rewording:
"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)."
64 | @@ -64,6 +65,8 @@ In what follows, we will define a function that derives a number of child keys f 65 | 66 | 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. 67 | 68 | +When deriving child keys, a 'hardened' child key can only be generated using a private key. This provides security advantages but reduces the usefulness of HD key derivation. It is typically used to separate 'accounts' from each other.
ACK this change.
I'd prefer the last sentence be dropped. Given the weird security properties of "normal" derivation, I think we should word things as though hardened derivation were the ordinary case, and non-hardened derivation is the one that has a sentence explaining why somebody would want to use it.
How about this wording to make it sound more ordinary:
"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 each other."
And another sentence added for non-hardened keys:
"This non-hardened result is typically used by a server to continually generate receive addresses without the ability to spend funds."
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.
50 | @@ -51,10 +51,11 @@ Addition (+) of two coordinate pair is defined as application of the EC group op 51 | Concatenation (||) is the operation of appending one byte sequence onto another. 52 | 53 | As standard conversion functions, we assume: 54 | -* 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. 55 | +* 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).
There seems to be a word missing here:
* 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 a public key).
Agree with adding "a" here (https://github.com/bitcoin/bips/pull/785/files#r1679635273).
50 | @@ -51,10 +51,11 @@ Addition (+) of two coordinate pair is defined as application of the EC group op 51 | Concatenation (||) is the operation of appending one byte sequence onto another. 52 | 53 | As standard conversion functions, we assume: 54 | -* 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. 55 | +* 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). 56 | * ser<sub>32</sub>(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first. 57 | * ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first. 58 | -* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted y coordinate. 59 | +* ser<sub>P</sub>(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) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted y coordinate.
Don't use a link to the master branch here, as it'll grow outdated over time.
64 | @@ -64,6 +65,8 @@ In what follows, we will define a function that derives a number of child keys f 65 | 66 | 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. 67 | 68 | +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.
I don't think the sentence with the word "typically" belongs here. BIP32 is a proposed specification, written in 2012. It's not a description of how things are in 2025. Any language here should relate to what it proposed in 2012.
107 | @@ -105,6 +108,8 @@ To compute the public child key of a parent private key: 108 | * CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), i) (works only for non-hardened child keys). 109 | 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. 110 | 111 | +The non-hardened result is typically used by a server to continually generate receive addresses without the ability to spend funds.
Again, this is describing a 2025 state of affairs, not a 2012 proposal.
I could see a separate section about "later adoption" being added perhaps, if that's considered useful, describing which parts of the proposal ended up being mainstream, and which ones weren't, but it should make it clear that that's separate from the historical proposal.
This pull request has not seen activity in several months, so Iām closing it for now. Please ping here to reopen it, if you want to continue working on it.
