How can extended public keys generate child public keys without generating the child private key in HD wallets?

There two ways to go from parent to child, non-hardened and hardened, the former allowing both (1) a parent private key -> child private key function and (2) a parent public key -> child public key function. (Hardened parent -> child relationship provides only function (1)).

If you look at :-

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Child_key_derivation_CKD_functions

the function (1) is defined as follows :-

k_i = I_L + k_par (mod n)                               (A)

n being the order of the Elliptic Curve Group E for Bitcoin's ECDSA (which has parameters secp256k1) - E being generated by the generator (or 'base') point G in E.

E is the Elliptic Curve Group over the finite field F_p (prime p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F), and consists of n elements (prime n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141) (note n is proportionately slightly less than p).

The elements of E are elements of F_p x F_p, and are points on the discrete elliptic curve over F_p. E is an 'additive' abelian group, and we can define scalar multiplication of elements of E by integers. G in E being a generator means E equals the set of all scalar multiples of G, ie E = {dG: d an integer}, denoted <G >.

By definition a private key k is a 256 bit integer in the range [1, n - 1]. And the associated public key is K given by

K = kG                               (B)

In the above BIP32 document, the notation point(p) is used to mean pG :-

point(p) = pG                     (C)

Thus in particular :-

point(k) = K

It is straightforward that the above scalar multiplication operation in E satisfies the distributive law :-

(a + b)P = aP + bP                (D)

where a, b are integers and P is any point in E.

If we imagine for the moment the above equation (A) didn't have the 'mod n' part then it is just adding two integers so we deduce from (D) and (A) :-

k_iG = I_LG + k_parG

But since G has order n, so that nG = 0, we can change the left hand side k_i value so that k_i is in the range [1, n - 1] (this is the 'mod n' part).

But this equation then just reads :-

K_i = I_LG + K_par                (E)

because of the above general relation K = kG between private key and public key, and because k_i is now a valid private key in the range [1, n - 1].

(Notice if the above procedure produces an unsuitable k_i, such as zero, then it is repeated with the next value of the index i).

If you now examine the above BIP32 document for "Public parent key -> public child key" it says :-

"The returned child key K_i is point(parse256(I_L)) + K_par"

which by the definition of 'point' in (C) above means a child public key of :-

K_i = I_LG + K_par              (F)

ie identical to the public key K_i of the child private key, as derived above at (E), as desired.

In short equation (A) just says add I_L to the parent private key to get the child private key. This is just addition of two integers (mod n).

And equation (F) just says add I_LG to the parent public key to get the child public key. This is an entirely different addition operation, namely 'point addition' on the elliptic curve group E.

The key to this working is that the 512 bit hash 'I' does not depend on the parent private key. With hardened child, the definition of 'I' is changed so it DOES depend on the parent private key, and thus a parent public key -> child public key function cannot be defined in this case.

You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.