<p>Change in this case represent external/internal chain. Usually if that's external chain, you can share it with parties. Imagine having a client which is obliged to send you bitcoin very often. If you'd give him <code>xpub</code> for the whole external chain, he can generate addresses on his own and you don't have to be bothered. It's not heavily used, but sometimes happens. </p>

<p>If this derivation was hardened, the external party couldn't derive child keys (addresses) for this chain. Also watch-only wallets wouldn't be a thing. </p>

<p>BIP44:</p>

<blockquote>
  <p>Constant 0 is used for external chain and constant 1 for internal
  chain (also known as change addresses). External chain is used for
  addresses that are meant to be visible outside of the wallet (e.g. for
  receiving payments). Internal chain is used for addresses which are
  not meant to be visible outside of the wallet and is used for return
  transaction change.</p>
  
  <p>Public derivation is used at this level.</p>
</blockquote>

CC BY-SA 4.0
2020-06-05T19:51:35.447Z
2020-06-05T19:51:35.447Z
Tony Sanak
<p>Being aware of the one weakness of BIP32: </p>

<blockquote>
  <p>One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.</p>
</blockquote>

<p>Why does BIP44 use non-hardened keys in the last 2 levels if it is still risky for the change/internal account? Wouldn't it be better to use always hardened keys?</p>

<pre><code>m / purpose' / coin_type' / account' / change / address_index
</code></pre>

<bip44>
Why not hardened keys in addresses BIP44?
Oscar Serna
# Why not hardened keys in addresses BIP44?

(Asked by: username_0 on 2020-06-05)

Being aware of the one weakness of BIP32:

> One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

Why does BIP44 use non-hardened keys in the last 2 levels if it is still risky for the change/internal account? Wouldn't it be better to use always hardened keys?

```
m / purpose' / coin_type' / account' / change / address_index

```

**Tags:** bip44


---

## 1 answers

### Answer by username_1 on 2020-06-05. Score: 4 | Accepted answer

Change in this case represent external/internal chain. Usually if that's external chain, you can share it with parties. Imagine having a client which is obliged to send you bitcoin very often. If you'd give him `xpub` for the whole external chain, he can generate addresses on his own and you don't have to be bothered. It's not heavily used, but sometimes happens.

If this derivation was hardened, the external party couldn't derive child keys (addresses) for this chain. Also watch-only wallets wouldn't be a thing.

BIP44:

> Constant 0 is used for external chain and constant 1 for internal
> chain (also known as change addresses). External chain is used for
> addresses that are meant to be visible outside of the wallet (e.g. for
> receiving payments). Internal chain is used for addresses which are
> not meant to be visible outside of the wallet and is used for return
> transaction change.
>
> Public derivation is used at this level.


---

