<blockquote>
<p>If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit).</p>
</blockquote>
<p>As Michael Folkson explains in that answer you linked:</p>
<blockquote>
<p>There is concatenation where 256 bits placed next to another 256 bits makes 512 bits. However, what you are referring to is <strong>scalar addition</strong>. A 256 bit number (256 bit parent private key) is added to another 256 bit number (left 256 bits of the SHA512) and the result modulo p (p = 2^256-2^32-977) is another 256 bit number.</p>
</blockquote>
<p>It in some sense will behave like classical addition (before the modulo operation).</p>
<p>Although I am not 100% sure where <code>p</code> is specifically defined, the modulo <code>p</code> operation where <code>p = 2^256-2^32-977</code> is the relevant operation that will shorten the resulting key to 256 bit. (because p is a 256 bit number)</p>
<p>So you add the left 256 bits to the parent private key to get the ( large 512 bit ) child private key, then you modulo <code>p</code> to shorten the result to 256 bit.</p>
<blockquote>
<p>Okay, let's say you and Michael are right. How will the parent's private key be obtained knowing the child's private key? If the module's operations are really used to obtain a 256-bit key, then inversion and obtaining the parent's private key cannot be performed at all... In the book, they say that it is &quot;relatively easy&quot; to obtain the parent's private key from knowing the child's private key.</p>
</blockquote>
<p>This was discussed partially here <a href="https://bitcoin.stackexchange.com/questions/117781/xpriv-can-be-calculated-from-the-xpub-child-private-key">Xpriv can be calculated from the xpub + child private key?</a></p>
<p>according to: <a href="https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82" rel="nofollow noreferrer">https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82</a></p>
<p>the equation for deriving the parent key from child is:</p>
<pre><code>child private key = (left 32 bytes + parent private key) % n

Bob solves for parent private key:

parent private key = (child private key - left 32 bytes) % n
</code></pre>
<p>Note here we are using modulo n which is the Secp256k1 curve order, this is a common operation in ECC. It is possible Michael meant modulo n but I cannot confirm this.</p>
<blockquote>
<p>The same formula you provided is also mentioned here. But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?)</p>
</blockquote>
<p>In this section you will notice <code>p</code> is being used and is explained to be a global constant in Bitcoin software but nothing more is said about it:
<a href="https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation" rel="nofollow noreferrer">https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation</a></p>
<p>This section <code>G</code> is being used:
<a href="https://developer.bitcoin.org/devguide/wallets.html#id5" rel="nofollow noreferrer">https://developer.bitcoin.org/devguide/wallets.html#id5</a></p>
<p>I know for certain <code>G</code> is used to derive public from private keys through scalar multiplication.</p>
<p>I do not want to state any incorrect facts about the utilization of these values, my opinion is that in this circumstance it makes more sense that the modulo operation is done via <code>n</code> because of <a href="https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82" rel="nofollow noreferrer">this</a> article that seems to detail it extremely well but since I don't know for certain I can only attempt to provide researched context.</p>

CC BY-SA 4.0
2023-04-02T22:07:24.350Z
Okay, let's say you and Michael are right. How will the parent's private key be obtained knowing the child's private key? If the module's operations are really used to obtain a 256-bit key, then inversion and obtaining the parent's private key cannot be performed at all... In the book, they say that it is "relatively easy" to obtain the parent's private key from knowing the child's private key.
dassd
CC BY-SA 4.0
2023-04-02T22:23:57.230Z
moving response to this to answer
Poseidon
CC BY-SA 4.0
2023-04-02T23:01:59.937Z
The same formula you provided is also mentioned [here](https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation). But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?). But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?
dassd
CC BY-SA 4.0
2023-04-02T23:45:34.780Z
They also talks [here](https://bitcoin.stackexchange.com/questions/38108/order-of-group-of-points-of-secp256k1) about it.
dassd
CC BY-SA 4.0
2023-04-03T03:55:58.320Z
responding in answer
Poseidon
CC BY-SA 4.0
2023-04-02T21:03:37.867Z
2023-04-03T04:08:18.117Z
2023-04-03T04:08:18.117Z
Poseidon
<p>What follows contains inaccurate notation and language on purpose, in order to make the conceptual explanation lighter and more straightforward.</p>
<hr />
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#extended-keys" rel="nofollow noreferrer">A BIP32 extended</a> private (&quot;<code>xprv</code>&quot;) or public (&quot;<code>xpub</code>&quot;) key is composed of two parts: the key itself and the chaincode. The key is either the private key k (for an <code>xprv</code>) or the public key K (for an <code>xpub</code>). The chaincode is a 256 bits integer, identical for both the private and public versions.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions" rel="nofollow noreferrer">BIP32 defines the CKD<sub>priv</sub>((k<sub>par</sub>, c<sub>par</sub>), i) → (k<sub>i</sub>, c<sub>i</sub>) function</a> that derives a child extended private key from a parent extended private key at a given index i. (k<sub>par</sub>, c<sub>par</sub>) are the private key and the chaincode of the parent, and (k<sub>i</sub>, c<sub>i</sub>) the private key and the chaincode of the child at index i. Let's call K<sub>par</sub> the public key corresponding to k<sub>par</sub>.</p>
<p>For unhardened derivation (<code>i &lt; 2^31</code>), CKD<sub>priv</sub> is defined as (loosely speaking):</p>
<ul>
<li>let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = K<sub>par</sub> || i). <em>(With all data serialized as bytes.)</em></li>
<li>c<sub>i</sub> is the rightmost 32 bytes of I.</li>
<li>k<sub>i</sub> is the leftmost 32 bytes of I (as an integer), added to k<sub>par</sub>.</li>
</ul>
<p>The insight in the above is that you can get I without knowing any secret: this makes sense, in some cases you may want an entity (such as an online server) to be able to derive public keys without having access to any secret. But this opens up the possibility to compute k<sub>par</sub> from (K<sub>par</sub>, c<sub>par</sub>) and k<sub>i</sub>, or in other words to compute the parent's <code>xprv</code> from the parent's <code>xpub</code> and any child private key (along with its index):</p>
<ol>
<li>From the parent's (K<sub>par</sub>, c<sub>par</sub>) and the index <code>i</code>, compute I.</li>
<li>Let I<sub>L</sub> be the leftmost 32 bytes of I.</li>
<li>Compute k<sub>par</sub> by substracting I<sub>L</sub> from k<sub>i</sub>.</li>
</ol>
<hr />
<p>Note by using hardened derivation, it's not possible to compute I<sub>L</sub> without the parent private key. This makes it impossible to use the above trick to get the parent private key from the child private key and parent extended key, at the cost of making it impossible to derive public keys without knowledge of the parent private key.</p>
<p>More on the security of BIP32 <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 4.0
2023-04-04T12:28:05.923Z
First of all, thanks for the reply. Yes, I generally know the process of getting the child's private key from the parent's private key and the left half of the hash. However, there is constant talk about adding those two elements and getting the child's private key, but no one is talking about what type of addition it is. In the end, as I understand it, it's simple addition, like 2+2=4, 3+6=9, etc.
dassd
CC BY-SA 4.0
2023-04-04T12:42:46.330Z
[Here](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#private-parent-key--private-child-key) it says that `ki is parse256(IL) + kpar ( mod n)` is used to obtain the child's private key. Since they don't point out anywhere that it's a special type of addition, I'd say it's just a "normal" addition. Also [here](https://github.com/wemeetagain/go-hdwallet/blob/master/hdwallet.go#L60)(hierarchical deterministic Bitcoin wallet implementation) `addPrivKes` is used which just does the "normal" addition of the left half of the hash and the parent's private key.
dassd
CC BY-SA 4.0
2023-04-04T12:46:16.800Z
The whole problem arose because [here](https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch) Michael Folkson said that it is concatenation and not "normal" addition. I think he is wrong? See also my other question related to the same topic. [Link](https://bitcoin.stackexchange.com/questions/117807/what-am-i-doing-wrong-in-calculating-child-private-key-in-hd-wallets-and-reversi)
dassd
CC BY-SA 4.0
2023-04-04T13:09:12.033Z
I don't understand your comments. What is your question? The trick is to substract `IL` from `ki`.
Antoine Poinsot
CC BY-SA 4.0
2023-04-04T13:23:22.823Z
Yes, but the problem was that I didn't know if when getting the child's private key, the scalar addition of the parent's private key and the left half of the hash was done or if it was a "special" operation denoted with `+`. The problem was caused by the answer to this [question](https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch), because I **misinterpreted** that concatenation was used. Since I thought it was concatenation, I didn't know what the opposite of that was, that is, what the `-` stands for.
dassd
CC BY-SA 4.0
2023-04-04T13:39:55.637Z
Yes, adding by the opposite is substracting.
Antoine Poinsot
CC BY-SA 4.0
2023-04-04T11:12:18.097Z
2023-04-04T11:18:46.400Z
2023-04-04T11:18:46.400Z
Antoine Poinsot
<p>I'm reading master bitcoin book and I came to the part related to HD wallets and how to create a Child private key (<a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#private-child-key-derivation" rel="nofollow noreferrer">link</a>). It says the following:</p>
<blockquote>
<p>The parent public key, chain code, and the index number are combined and hashed with the HMAC-SHA512 algorithm to produce a 512-bit hash. This 512-bit hash is split into two 256-bit halves. The right-half 256 bits of the hash output become the chain code for the child. <strong>The left-half 256 bits of the hash are added to the parent key to produce the child private key.</strong> In Extending a parent private key to create a child private key, we see this illustrated with the index set to 0 to produce the &quot;zero&quot; (first by index) child of the parent.</p>
</blockquote>
<p>The bolded sentence causes me misunderstanding. What type of <em><strong>addition</strong></em> is this? If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit). Is this perhaps referring to addition in the context of the &quot;logical and&quot; between the left hash result and the parent's private key? What type of addition is meant here when the result should be 256-bit? Some answer is given <a href="https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch">here</a>, but I'm still not clear. The answer is related to the use of modules.</p>
<p>What further confuses me is that the book says that if the child's private key is known, the parent's private key can be determined? That would make perfect sense to me if it was about adding the left half of the hash to the parent's private key. You simply remove the part related to the hash from the 512-bit result and get parent's private key. However, how can it be done here?</p>

CC BY-SA 4.0
2024-01-10T21:54:07.473Z
Does this answer your question? [Derivation of parent private key from non-hardened child](https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child)
Antoine Poinsot
<private-key><bip32-hd-wallets>
How are children's private keys in HD wallets obtained and how can knowing them reveal the parent's private key?
dassd
# How are children's private keys in HD wallets obtained and how can knowing them reveal the parent's private key?

(Asked by: username_0 on 2023-04-02)

I'm reading master bitcoin book and I came to the part related to HD wallets and how to create a Child private key ([link](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#private-child-key-derivation)). It says the following:

> The parent public key, chain code, and the index number are combined and hashed with the HMAC-SHA512 algorithm to produce a 512-bit hash. This 512-bit hash is split into two 256-bit halves. The right-half 256 bits of the hash output become the chain code for the child. **The left-half 256 bits of the hash are added to the parent key to produce the child private key.** In Extending a parent private key to create a child private key, we see this illustrated with the index set to 0 to produce the "zero" (first by index) child of the parent.

The bolded sentence causes me misunderstanding. What type of ***addition*** is this? If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit). Is this perhaps referring to addition in the context of the "logical and" between the left hash result and the parent's private key? What type of addition is meant here when the result should be 256-bit? Some answer is given [here](https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch), but I'm still not clear. The answer is related to the use of modules.

What further confuses me is that the book says that if the child's private key is known, the parent's private key can be determined? That would make perfect sense to me if it was about adding the left half of the hash to the parent's private key. You simply remove the part related to the hash from the 512-bit result and get parent's private key. However, how can it be done here?

**Tags:** private-key, bip32-hd-wallets

> **Comments:**
> **username_1**: Does this answer your question? [Derivation of parent private key from non-hardened child](https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child)  

---

## 2 answers

### Answer by username_2 on 2023-04-02. Score: 1 | Accepted answer

> If the classical addition of the left 256 bits of the hash result to the private key of the parent is implemented, then it will lead to a 512-bit private key of the child, which is not correct (the private key should be 256-bit).

As Michael Folkson explains in that answer you linked:

> There is concatenation where 256 bits placed next to another 256 bits makes 512 bits. However, what you are referring to is **scalar addition**. A 256 bit number (256 bit parent private key) is added to another 256 bit number (left 256 bits of the SHA512) and the result modulo p (p = 2^256-2^32-977) is another 256 bit number.

It in some sense will behave like classical addition (before the modulo operation).

Although I am not 100% sure where `p` is specifically defined, the modulo `p` operation where `p = 2^256-2^32-977` is the relevant operation that will shorten the resulting key to 256 bit. (because p is a 256 bit number)

So you add the left 256 bits to the parent private key to get the ( large 512 bit ) child private key, then you modulo `p` to shorten the result to 256 bit.

> Okay, let's say you and Michael are right. How will the parent's private key be obtained knowing the child's private key? If the module's operations are really used to obtain a 256-bit key, then inversion and obtaining the parent's private key cannot be performed at all... In the book, they say that it is "relatively easy" to obtain the parent's private key from knowing the child's private key.

This was discussed partially here [Xpriv can be calculated from the xpub + child private key?](https://bitcoin.stackexchange.com/questions/117781/xpriv-can-be-calculated-from-the-xpub-child-private-key)

according to: <https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82>

the equation for deriving the parent key from child is:

```
child private key = (left 32 bytes + parent private key) % n

Bob solves for parent private key:

parent private key = (child private key - left 32 bytes) % n

```

Note here we are using modulo n which is the Secp256k1 curve order, this is a common operation in ECC. It is possible Michael meant modulo n but I cannot confirm this.

> The same formula you provided is also mentioned here. But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?)

In this section you will notice `p` is being used and is explained to be a global constant in Bitcoin software but nothing more is said about it:
<https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation>

This section `G` is being used:
<https://developer.bitcoin.org/devguide/wallets.html#id5>

I know for certain `G` is used to derive public from private keys through scalar multiplication.

I do not want to state any incorrect facts about the utilization of these values, my opinion is that in this circumstance it makes more sense that the modulo operation is done via `n` because of [this](https://medium.com/@blainemalone01/hd-wallets-why-hardened-derivation-matters-89efcdc71671#cc82) article that seems to detail it extremely well but since I don't know for certain I can only attempt to provide researched context.

> **Comments:**
> **username_0**: Okay, let's say you and Michael are right. How will the parent's private key be obtained knowing the child's private key? If the module's operations are really used to obtain a 256-bit key, then inversion and obtaining the parent's private key cannot be performed at all... In the book, they say that it is "relatively easy" to obtain the parent's private key from knowing the child's private key.  
> **username_2**: moving response to this to answer  
> **username_0**: The same formula you provided is also mentioned [here](https://developer.bitcoin.org/devguide/wallets.html#hierarchical-deterministic-key-creation). But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?). But here they use G instead of n. I know that G is a generic point (a point on an elliptic curve) used to generate a public key from a private key. So is n actually G?  
> **username_0**: They also talks [here](https://bitcoin.stackexchange.com/questions/38108/order-of-group-of-points-of-secp256k1) about it.  
> **username_2**: responding in answer  

---

### Answer by username_1 on 2023-04-04. Score: 1

What follows contains inaccurate notation and language on purpose, in order to make the conceptual explanation lighter and more straightforward.

---

[A BIP32 extended](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#extended-keys) private ("`xprv`") or public ("`xpub`") key is composed of two parts: the key itself and the chaincode. The key is either the private key k (for an `xprv`) or the public key K (for an `xpub`). The chaincode is a 256 bits integer, identical for both the private and public versions.

[BIP32 defines the CKDpriv((kpar, cpar), i) → (ki, ci) function](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions) that derives a child extended private key from a parent extended private key at a given index i. (kpar, cpar) are the private key and the chaincode of the parent, and (ki, ci) the private key and the chaincode of the child at index i. Let's call Kpar the public key corresponding to kpar.

For unhardened derivation (`i < 2^31`), CKDpriv is defined as (loosely speaking):

* let I = HMAC-SHA512(Key = cpar, Data = Kpar || i). *(With all data serialized as bytes.)*
* ci is the rightmost 32 bytes of I.
* ki is the leftmost 32 bytes of I (as an integer), added to kpar.

The insight in the above is that you can get I without knowing any secret: this makes sense, in some cases you may want an entity (such as an online server) to be able to derive public keys without having access to any secret. But this opens up the possibility to compute kpar from (Kpar, cpar) and ki, or in other words to compute the parent's `xprv` from the parent's `xpub` and any child private key (along with its index):

1. From the parent's (Kpar, cpar) and the index `i`, compute I.
2. Let IL be the leftmost 32 bytes of I.
3. Compute kpar by substracting IL from ki.

---

Note by using hardened derivation, it's not possible to compute IL without the parent private key. This makes it impossible to use the above trick to get the parent private key from the child private key and parent extended key, at the cost of making it impossible to derive public keys without knowledge of the parent private key.

More on the security of BIP32 [here](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security).

> **Comments:**
> **username_0**: First of all, thanks for the reply. Yes, I generally know the process of getting the child's private key from the parent's private key and the left half of the hash. However, there is constant talk about adding those two elements and getting the child's private key, but no one is talking about what type of addition it is. In the end, as I understand it, it's simple addition, like 2+2=4, 3+6=9, etc.  
> **username_0**: [Here](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#private-parent-key--private-child-key) it says that `ki is parse256(IL) + kpar ( mod n)` is used to obtain the child's private key. Since they don't point out anywhere that it's a special type of addition, I'd say it's just a "normal" addition. Also [here](https://github.com/wemeetagain/go-hdwallet/blob/master/hdwallet.go#L60)(hierarchical deterministic Bitcoin wallet implementation) `addPrivKes` is used which just does the "normal" addition of the left half of the hash and the parent's private key.  
> **username_0**: The whole problem arose because [here](https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch) Michael Folkson said that it is concatenation and not "normal" addition. I think he is wrong? See also my other question related to the same topic. [Link](https://bitcoin.stackexchange.com/questions/117807/what-am-i-doing-wrong-in-calculating-child-private-key-in-hd-wallets-and-reversi)  
> **username_1**: I don't understand your comments. What is your question? The trick is to substract `IL` from `ki`.  
> **username_0**: Yes, but the problem was that I didn't know if when getting the child's private key, the scalar addition of the parent's private key and the left half of the hash was done or if it was a "special" operation denoted with `+`. The problem was caused by the answer to this [question](https://bitcoin.stackexchange.com/questions/115392/the-left-half-256-bits-of-the-hash-are-added-to-the-parent-key-to-produce-the-ch), because I **misinterpreted** that concatenation was used. Since I thought it was concatenation, I didn't know what the opposite of that was, that is, what the `-` stands for.  
> **username_1**: Yes, adding by the opposite is substracting.  

---

