<p>Bip44 doesn't protect anything, if the user has master root key, they could get access to all the other accounts private keys.</p>

<p>Your path is wrong, it should be like that:</p>

<p><em>m / purpose' / coin_type' / <strong>account</strong>' / change / address_index</em></p>

<p>What you should do is generating child master private key for the following path:</p>

<p><em>m/44'/0'/1'/</em></p>

<p>Now the user has access only to account number "1" and should generate addresses using that child master private key and the following path:</p>

<p><em>m/changeAddress/addressIndex</em></p>

CC BY-SA 3.0
2018-03-05T08:50:45.960Z
Thanks for point out the mistake. I will try to clarify my misconception and make my question clear. I understand hardening is helps to protect the parent private key being compromised if extended public key + child private key is compromised. However, I realize in BIP44, the `change` and `address_index` is non-hardened. That's why I am concerned that if any private key I derived from this path got compromised, does it means all the other private keys with the same account derived from the path is compromised as well.
Calvin Lau
CC BY-SA 3.0
2018-03-05T08:57:20.020Z
Never, they'll need the master private key to get access to other accounts private keys.
Tailer
CC BY-SA 3.0
2018-03-05T08:58:01.773Z
How about within the same account? e.g. the private key for `m/44'/0'/1'/0/0` get compromised, with the extended public key, does it means private keys of `m/44'/0'/1'/0/n` are all said to be compromised?
Calvin Lau
CC BY-SA 3.0
2018-03-05T08:59:34.963Z
Not using WIF private key, they need the account master private key.
Tailer
CC BY-SA 3.0
2018-03-05T09:01:56.680Z
with the extended public key they may just see the addresses, but never the private keys.
Tailer
CC BY-SA 3.0
2018-03-05T09:09:43.217Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/74045/discussion-between-calvin-lau-and-adam).
Calvin Lau
CC BY-SA 3.0
2018-03-05T09:13:37.037Z
Oh I just notice in your answer you mention `generate addresses using that child master private key`. In my case I want to use an extended public key to generate address (because I need to generate address on the fly). So what I will putting in my application would be the extended public key at path `m/44'/0'/1'/0`. Does it means the vulnerability I mentions is valid?
Calvin Lau
CC BY-SA 3.0
2018-03-05T15:24:20.520Z
I have rethink the whole thing and try to summarize. Does it means that: 1) If I use a master private key to derive a public key, it is a hardened public key and I do not need to worry about compromise of parent or siblings private key if child private key is exposed. 2) If I decide to use an extended public key to derive addresses, then I am subject to the vulnerability, no matter I am using the BIP44 derivation path `m/44'/0'/1'/0` or other path that ends without prime.
Calvin Lau
CC BY-SA 3.0
2018-03-05T08:33:42.953Z
2018-03-05T08:33:42.953Z
Tailer
<p>I understand that with</p>

<ul>
<li>Un-hardened parent extended public key</li>
<li>child private key</li>
</ul>

<p>This will leads to compromise of parent private key and so all the private keys of siblings</p>

<p>BIP44 suggests the path
<code>
m / purpose' / coin_type' / account' / change / address_index
</code></p>

<p>Let's say I use the path <code>m/44'/0'/0'/0</code> to derive  public keys for account <code>0</code></p>

<p>Since The <code>change</code> and <code>address_index</code> is not hardened. And in my application I will have the <code>extended public key</code> at level <code>m/44'/0'/0'/0</code> revealed (to derive addresses), does it means that if any of the private keys derived at the <code>address_index</code> level is compromised, all the private keys within the same account may also be compromised?</p>

<p>So with this path only avoid further compromise up to</p>

<ul>
<li>Other accounts and</li>
<li>Further up to the master key?</li>
</ul>

<p>Am I correct?</p>

<wallet><address><address-generation><bip32-hd-wallets>
Does BIP44 key derivation path protects private keys derived within same account?
Calvin Lau
# Does BIP44 key derivation path protects private keys derived within same account?

(Asked by: username_0 on 2018-03-05)

I understand that with

* Un-hardened parent extended public key
* child private key

This will leads to compromise of parent private key and so all the private keys of siblings

BIP44 suggests the path
`m / purpose' / coin_type' / account' / change / address_index`

Let's say I use the path `m/44'/0'/0'/0` to derive public keys for account `0`

Since The `change` and `address_index` is not hardened. And in my application I will have the `extended public key` at level `m/44'/0'/0'/0` revealed (to derive addresses), does it means that if any of the private keys derived at the `address_index` level is compromised, all the private keys within the same account may also be compromised?

So with this path only avoid further compromise up to

* Other accounts and
* Further up to the master key?

Am I correct?

**Tags:** wallet, address, address-generation, bip32-hd-wallets


---

## 1 answers

### Answer by username_1 on 2018-03-05. Score: 1

Bip44 doesn't protect anything, if the user has master root key, they could get access to all the other accounts private keys.

Your path is wrong, it should be like that:

*m / purpose' / coin\_type' / **account**' / change / address\_index*

What you should do is generating child master private key for the following path:

*m/44'/0'/1'/*

Now the user has access only to account number "1" and should generate addresses using that child master private key and the following path:

*m/changeAddress/addressIndex*

> **Comments:**
> **username_0**: Thanks for point out the mistake. I will try to clarify my misconception and make my question clear. I understand hardening is helps to protect the parent private key being compromised if extended public key + child private key is compromised. However, I realize in BIP44, the `change` and `address_index` is non-hardened. That's why I am concerned that if any private key I derived from this path got compromised, does it means all the other private keys with the same account derived from the path is compromised as well.  
> **username_1**: Never, they'll need the master private key to get access to other accounts private keys.  
> **username_0**: How about within the same account? e.g. the private key for `m/44'/0'/1'/0/0` get compromised, with the extended public key, does it means private keys of `m/44'/0'/1'/0/n` are all said to be compromised?  
> **username_1**: Not using WIF private key, they need the account master private key.  
> **username_1**: with the extended public key they may just see the addresses, but never the private keys.  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/74045/discussion-between-calvin-lau-and-adam).  
> **username_0**: Oh I just notice in your answer you mention `generate addresses using that child master private key`. In my case I want to use an extended public key to generate address (because I need to generate address on the fly). So what I will putting in my application would be the extended public key at path `m/44'/0'/1'/0`. Does it means the vulnerability I mentions is valid?  
> **username_0**: I have rethink the whole thing and try to summarize. Does it means that: 1) If I use a master private key to derive a public key, it is a hardened public key and I do not need to worry about compromise of parent or siblings private key if child private key is exposed. 2) If I decide to use an extended public key to derive addresses, then I am subject to the vulnerability, no matter I am using the BIP44 derivation path `m/44'/0'/1'/0` or other path that ends without prime.  

---

