<p>You have interpreted that correctly. If your child extended private key belonging to path <code>m/44'/60'/4'/0</code> is leaked, the attacker cannot figure out the child extended private key from path <code>m/44'/60'/4'/1</code>.</p>

<p>The non-hardened derivation for child private key is <code>kchild = kpar + hash(Kpar, cpar, i)</code>. Here <code>k</code> represents private key, <code>K</code> is the public key, <code>c</code> is the chain code and <code>i</code> is the index number. If you note, the index number sits inside the hash function in the child key derivation. Since hash functions are undeterministic, slight change in its input can have a very different effect on the output. Hence incrementing the index number <code>i</code> from 0 to 1 will yield completely different result and hence cannot be back-calculated.</p>

<p>However, do note that according to <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" rel="nofollow noreferrer">BIP 44</a> derivation, the index number after the account level denotes whether it is receiving or change. The child extended private key that has been leaked (index = 0) will act as a parent private key to derive <strong>all receiving</strong> addresses belonging to account 5. Thus all receiving addressees derived from the 5th accounts are compromised in your case.</p>

CC BY-SA 4.0
2019-09-26T05:39:24.890Z
Whey you say 5th account, do you mean 5th level ? If not, can you give an example for the same.
Sibi
CC BY-SA 4.0
2019-09-26T05:43:46.633Z
@Sibi BIP 44 key derivation has the path m / purpose' / coin_type' / account' / change / address_index. If you check the `xprv` you mentioned, you are using BIP 44, so purpose is 44'. `coin_type` is 60' so that is ETH. `account` is 4' so that is the 5th account. you can increment index at the account level and generate number of different accounts from which you can then generate receiving and change addresses. Users can use accounts to organize funds in same way as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc.
Ugam Kamat
CC BY-SA 4.0
2019-09-25T10:40:16.307Z
2019-09-25T15:57:17.430Z
2019-09-25T15:57:17.430Z
Ugam Kamat
<p>Let's say the following keys are leaked:</p>

<ul>
<li>44'/60'/4'/0 extended private key</li>
<li>44'/60'/4'/0 extended public key (you can just derive this from the above private key)</li>
</ul>

<p>Now using the above information can we derive the private or public key of this path:</p>

<p>44'/60'/4'/1</p>

<p>I don't think we can derive the private key because to get the private
or public key of 44'/60'/4'/1, we need to know the private key or
public key for the path <code>44'/60'/4'</code>. But that's not something which
we can calculate from the above information. Is my understanding right ?</p>

<bip32-hd-wallets><deterministic-wallets>
Consequences of sibling keys when xpub and xprv are leaked
Sibi
# Consequences of sibling keys when xpub and xprv are leaked

(Asked by: username_0 on 2019-09-25)

Let's say the following keys are leaked:

* 44'/60'/4'/0 extended private key
* 44'/60'/4'/0 extended public key (you can just derive this from the above private key)

Now using the above information can we derive the private or public key of this path:

44'/60'/4'/1

I don't think we can derive the private key because to get the private
or public key of 44'/60'/4'/1, we need to know the private key or
public key for the path `44'/60'/4'`. But that's not something which
we can calculate from the above information. Is my understanding right ?

**Tags:** bip32-hd-wallets, deterministic-wallets


---

## 1 answers

### Answer by username_1 on 2019-09-25. Score: 1 | Accepted answer

You have interpreted that correctly. If your child extended private key belonging to path `m/44'/60'/4'/0` is leaked, the attacker cannot figure out the child extended private key from path `m/44'/60'/4'/1`.

The non-hardened derivation for child private key is `kchild = kpar + hash(Kpar, cpar, i)`. Here `k` represents private key, `K` is the public key, `c` is the chain code and `i` is the index number. If you note, the index number sits inside the hash function in the child key derivation. Since hash functions are undeterministic, slight change in its input can have a very different effect on the output. Hence incrementing the index number `i` from 0 to 1 will yield completely different result and hence cannot be back-calculated.

However, do note that according to [BIP 44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) derivation, the index number after the account level denotes whether it is receiving or change. The child extended private key that has been leaked (index = 0) will act as a parent private key to derive **all receiving** addresses belonging to account 5. Thus all receiving addressees derived from the 5th accounts are compromised in your case.

> **Comments:**
> **username_0**: Whey you say 5th account, do you mean 5th level ? If not, can you give an example for the same.  
> **username_1**: @username_0 BIP 44 key derivation has the path m / purpose' / coin_type' / account' / change / address_index. If you check the `xprv` you mentioned, you are using BIP 44, so purpose is 44'. `coin_type` is 60' so that is ETH. `account` is 4' so that is the 5th account. you can increment index at the account level and generate number of different accounts from which you can then generate receiving and change addresses. Users can use accounts to organize funds in same way as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc.  

---

