BIP32: edits by ddustin for clarity

jonatack commented at 8:04 pm on July 25, 2025: member

Picks up @ddustin’s work in #785, updated with the latest reviewers’ feedback.

jonatack added the label Proposed BIP modification on Jul 25, 2025

jonatack added the label Pending acceptance on Jul 25, 2025

jonatack renamed this:
~~BIP32: edits for clarity~~
BIP32: edits by ddustin for clarity
on Jul 25, 2025

in bip-0032.mediawiki:58 in 3fa6bc7588 outdated

51@@ -52,10 +52,10 @@ Addition (+) of two coordinate pair is defined as application of the EC group op
52 Concatenation (||) is the operation of appending one byte sequence onto another.
53 
54 As standard conversion functions, we assume:
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.
56+* 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).
57 * ser<sub>32</sub>(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
58 * ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first.
59-* 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.
60+* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) (i.e., the public key) as a byte sequence using [https://github.com/bitcoin-core/secp256k1/blob/b9313c6e/include/secp256k1.h#L227 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.

murchandamus commented at 11:26 pm on July 25, 2025:

#785 had another sentence that is omitted here, so I was wondering whether that was an oversight or deliberate.

0* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) (i.e., the public key) as a byte sequence using [https://github.com/bitcoin-core/secp256k1/blob/b9313c6e/include/secp256k1.h#L227 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.
1** [https://github.com/bitcoin-core/secp256k1 Libsecp256k1]'s pubkey_serialize and pubkey_parse functions implement this format.

jonatack commented at 0:08 am on July 27, 2025:

Thanks! I had overlooked that line. Updated.

murchandamus commented at 11:27 pm on July 25, 2025: member

Compared to #785 and found to match the old pull request in combination with the outstanding review comments from the BIPs authors except for the mentioned spot.

jonatack force-pushed on Jul 27, 2025

murchandamus commented at 7:01 pm on July 28, 2025: member

@sipa: Could you take another look at these few lines?

murchandamus requested review from sipa on Feb 28, 2026

in bip-0032.mediawiki:55 in 879066d3ea

51@@ -50,10 +52,11 @@ Addition (+) of two coordinate pair is defined as application of the EC group op
52 Concatenation (||) is the operation of appending one byte sequence onto another.
53 
54 As standard conversion functions, we assume:
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.
56+* 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).

sipa commented at 5:46 pm on March 5, 2026:

It’s not just similar to making a public key, but exactly that.

What about (i.e., the operation used to compute a public key from a private key).

jonatack commented at 7:10 pm on March 5, 2026:

Thanks @sipa, done.

in bip-0032.mediawiki:59 in 879066d3ea

56+* 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).
57 * ser<sub>32</sub>(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
58 * ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first.
59-* 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.
60+* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) (i.e., the public key) as a byte sequence using [https://github.com/bitcoin-core/secp256k1/blob/b9313c6e/include/secp256k1.h#L227 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.
61+** [https://github.com/bitcoin-core/secp256k1 Libsecp256k1]'s pubkey_serialize and pubkey_parse functions implement this format.

sipa commented at 5:47 pm on March 5, 2026:

I don’t think it’s valuable to link to libsecp256k1 here. Literally every implementation of EC cryptography supports this.

jonatack commented at 7:12 pm on March 5, 2026:

Done, removed the line 59 link. Kept the one in line 58 for now, unless it’s not useful there either.

sipa commented at 7:15 pm on March 5, 2026:

Yeah, I was referring to both. If you want to link to something, the spec itself perhaps? https://www.secg.org/sec1-v2.pdf section 2.3.3.

jonatack commented at 7:23 pm on March 5, 2026:

Thanks! Updated with link to the spec itself.

in bip-0032.mediawiki:69 in 879066d3ea

65@@ -63,6 +66,8 @@ In what follows, we will define a function that derives a number of child keys f
66 
67 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.
68 
69+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.

sipa commented at 5:47 pm on March 5, 2026:

I don’t think this adds anything. It’s in the wrong section (derivation functions are below), and I think it’s already mentioned what effect they have (the “It is also the reason for the existence of hardened keys” and later under “Security”, and “It is only defined for non-hardened child keys. " under “Public parent key → public child key”).

jonatack commented at 7:12 pm on March 5, 2026:

Thanks, dropped.

murchandamus added the label PR Author action required on Mar 5, 2026

jonatack force-pushed on Mar 5, 2026

jonatack removed the label PR Author action required on Mar 5, 2026

BIP32: edits by ddustin for clarity (picks up PR785)

Co-authored-by: Pieter Wuille <pieter@wuille.net>
Co-authored-by: Murch <murch@murch.one>
Co-authored-by: Jon Atack <jon@atack.com>

dfdbbd1ff6

jonatack force-pushed on Mar 5, 2026

sipa commented at 7:22 pm on March 5, 2026: member

ACK dfdbbd1ff69c88ad9c938d17c8378de87370af76

murchandamus removed the label Pending acceptance on Mar 5, 2026

murchandamus commented at 7:29 pm on March 5, 2026: member

LGTM

murchandamus merged this on Mar 5, 2026

murchandamus closed this on Mar 5, 2026

jonatack deleted the branch on Mar 5, 2026

BIP32: edits by ddustin for clarity #1903