user63214: According to the documentation on bitcoin.org and the Mastering Bitcoin book, you can use an extended public key to create child public keys in HD wallets by combining the lefthand side of the hash output of the parent chain code + parent public key + index:

The seemingly-random 256 bits on the lefthand side of the hash output are used as the integer value to be combined with either the parent private key or parent public key to, respectively, create either a child private key or child public key

I understand how this lefthand side output can be combined with the parent private key to generate the child private key, which in turn can be used to generate a valid child public key. 
How is it possible that the child public key generated by combining the hash output with the parent public key corresponds to the child private key generated separately by combining the same hash output with the parent private key?
I thought that in was impossible to generate a public key without knowing exactly what the private key was. How is the relationship between child private and public keys (K = k*G) maintained when they are generated separately in this way?.

user-1: 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 :-
ki = IL + kpar (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 Fp (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 Fp x Fp, and are points on the discrete elliptic curve over Fp. 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) :-
kiG = ILG + kparG
But since G has order n, so that nG = 0, we can change the left hand side ki value so that ki is in the range [1, n - 1] (this is the 'mod n' part).
But this equation then just reads :-
Ki = ILG + Kpar                (E)
because of the above general relation K = kG between private key and public key, and because ki is now a valid private key in the range [1, n - 1].
(Notice if the above procedure produces an unsuitable ki, 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 Ki is point(parse256(IL)) + Kpar"
which by the definition of 'point' in (C) above means a child public key of :-
Ki = ILG + Kpar              (F)
ie identical to the public key Ki of the child private key, as derived above at (E), as desired.
In short equation (A) just says add IL 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 ILG 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.

user12983: 
How is the relationship between child private and public keys (K = k*G)

(a+b)*G = aG + bG

user63214: Upon a bit more searching, I found the derivation for getting the child public key without the private key here:
child_private_key == (parent_private_key + lefthand_hash_output) % G
child_public_key == point( (parent_private_key + lefthand_hash_output) % G )
child_public_key == point(child_private_key) == parent_public_key + point(lefthand_hash_output)

In terms of K, k and G where prime denotes the child and h denotes the left-hand hash output:
k' = (k + h) % G
K' = point ( (k + h) % G)
K' = point (k')
K' = K + point(h)

Here are the exact implementation details from the BIP 32 documentation

63214: <p>According to the documentation on <a href="https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation" rel="noreferrer">bitcoin.org</a> and the Mastering Bitcoin book, you can use an extended public key to create child public keys in HD wallets by combining the lefthand side of the hash output of the parent chain code + parent public key + index:</p>

<blockquote>
  <p>The seemingly-random 256 bits on the lefthand side of the hash output are used as the integer value to be combined with either the parent private key or parent public key to, respectively, create either a child private key or child public key</p>
</blockquote>

<p>I understand how this lefthand side output can be combined with the parent private key to generate the child private key, which in turn can be used to generate a valid child public key. </p>

<p>How is it possible that the child public key generated by combining the hash output with the parent public key corresponds to the child private key generated separately by combining the same hash output with the parent private key?</p>

<p>I thought that in was impossible to generate a public key without knowing exactly what the private key was. How is the relationship between child private and public keys (K = k*G) maintained when they are generated separately in this way?.</p>
 -1: <p>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)).</p>

<p>If you look at :-</p>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Child_key_derivation_CKD_functions" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Child_key_derivation_CKD_functions</a></p>

<p>the function (1) is defined as follows :-</p>

<p><em>k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n)</em> &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;(A)</p>

<p>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.</p>

<p>E is the Elliptic Curve Group over the finite field F<sub>p</sub> (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).</p>

<p>The elements of E are elements of F<sub>p</sub> x F<sub>p</sub>, and are points on the discrete elliptic curve over F<sub>p</sub>. 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  &lt;G &gt;.</p>

<p>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</p>

<p><em>K = kG</em> &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;(B)</p>

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

<p><em>point(p) = pG</em> &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;(C)</p>

<p>Thus in particular :-</p>

<p><em>point(k) = K</em></p>

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

<p><em>(a + b)P = aP + bP</em> &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;(D)</p>

<p>where a, b are integers and P is any point in E.</p>

<p>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) :-</p>

<p>k<sub>i</sub>G = I<sub>L</sub>G + k<sub>par</sub>G</p>

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

<p>But this equation then just reads :-</p>

<p>K<sub>i</sub> = I<sub>L</sub>G + K<sub>par</sub> &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;(E)</p>

<p>because of the above general relation K = kG between private key and public key, and because k<sub>i</sub> is now a valid private key in the range [1, n - 1].</p>

<p>(Notice if the above procedure produces an unsuitable k<sub>i</sub>, such as zero, then it is repeated with the next value of the index i).</p>

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

<p>"The returned child key K<sub>i</sub> is <strong>point</strong>(parse256(I<sub>L</sub>)) + K<sub>par</sub>"</p>

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

<p>K<sub>i</sub> = <strong>I<sub>L</sub>G</strong> + K<sub>par</sub> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(F)</p>

<p>ie identical to the public key K<sub>i</sub> of the child private key, as derived above at (E), as desired.</p>

<p>In short equation (A) just says add I<sub>L</sub> to the parent private key to get the child private key. This is just addition of two integers (mod n).</p>

<p>And equation (F) just says add <strong>I<sub>L</sub>G</strong> 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.</p>

<p>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.</p>
 12983: <blockquote>
  <p>How is the relationship between child private and public keys (K = k*G)</p>
</blockquote>

<p>(a+b)*G = aG + bG</p>
 63214: <p>Upon a bit more searching, I found the derivation for getting the child public key without the private key <a href="https://bitcoin.org/en/developer-guide#public-key-formats" rel="nofollow noreferrer">here</a>:</p>

<pre><code>child_private_key == (parent_private_key + lefthand_hash_output) % G
child_public_key == point( (parent_private_key + lefthand_hash_output) % G )
child_public_key == point(child_private_key) == parent_public_key + point(lefthand_hash_output)
</code></pre>

<p>In terms of <em>K</em>, <em>k</em> and <em>G</em> where prime denotes the child and <em>h</em> denotes the left-hand hash output:</p>

<pre><code>k' = (k + h) % G
K' = point ( (k + h) % G)
K' = point (k')
K' = K + point(h)
</code></pre>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Public_parent_key_rarr_public_child_key" rel="nofollow noreferrer">Here</a> are the exact implementation details from the BIP 32 documentation</p>
