<p>It is possible for a custom implementation use hardened keys for all the leaf keys to enhance security in case of a single private key leak. This scheme will be incompatible with the standard compliant wallets.</p>

<p>The BIP32 and BIP44 standards, use hardened keys up until the "account" level:</p>

<p><code>m/44'/0'/account'</code></p>

<p>but use non-hardened keys for the receive (a.k.a. external) and change (a.k.a. internal) addresses.</p>

<p>This is done to isolate the accounts and allow some flexibility:</p>

<ul>
<li>Use watch-only wallets by sharing the hardened xpub of the account.</li>
<li>Derive new receive addresses without the need of the account private key (vs hardened derivation where the parent private key is required). This is a hassle because the account xpriv is usually encrypted and you need the user password every time.</li>
<li>Store a single secret (the hardened xpriv) per account. Every time a transaction needs to be signed the correct child private key is derived on demand.</li>
</ul>

<p>The security model of the BIP32/BIP44 is to use only one private key per account. The revealing of a non-hardened child private key equals to revealing of the account private key. If sharing of private keys is a requirement, it is preferable to create a new account and share the xpriv vs the non-hardened child private key of an existing account.</p>

CC BY-SA 3.0
2015-06-07T13:27:31.797Z
2015-06-07T13:27:31.797Z
John L. Jegutanis
<p>The simple (and I <em>believe</em> correct) answer is: use hardened keys everywhere except where a need for watching-only wallets is perceived, e.g. below the "account" level. A watching only-wallet in this scenario will be able to both create new addresses, and monitor the balance of an account.</p>

<p>Hence <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" rel="noreferrer">BIP-44</a>'s path is:</p>

<pre><code>m/44'/0'/account'/change/index
</code></pre>

<p>The clear result is that each account's xpub must be exported separately from a cold wall for import into a watching-only wallet.</p>

<p>Almost every wallet I've looked at uses this method (the exception being Wallet32 for Android prior to v0.2.5 released May 15 2014). Reference: <a href="https://bitcointalk.org/index.php?topic=1000544.msg10862297#msg10862297" rel="noreferrer">this bitcointalk post</a>, which links to <a href="https://onedrive.live.com/redir?resid=584F122BA17116EE%21313" rel="noreferrer">this spreadsheet</a>.</p>

<p>edited to add: Also of some relevance is the level at which an xpub is exported. Almost every wallet which supports xpub exports does so at the account level (same reference as above), which includes both the external and internal (change) chains of a single account. (The exception is MyCelium for iOS, however this is <a href="https://bitcointalk.org/index.php?topic=965932.msg10564840#msg10564840" rel="noreferrer">considered a bug</a> by the MyCelium devs.)</p>

CC BY-SA 3.0
2015-06-07T12:39:24.993Z
Why isn't the change level of the BIP44 tree a hardened key? It only permits the stealing of the change addresses if an index key is revealed, I guess, but still why not?
morsecoder
CC BY-SA 3.0
2015-06-07T14:02:48.430Z
@StephenM347 For the use-case of using an xpub to generate new receive addresses, I agree it would make sense to harden the change level. However I suspect the use-case of using an xpub to monitor the balance of an account is also very popular, and would require either a non-hardened change level, or the export of two xpubs which isn't very user-friendly nor easy to explain to newbies IMO.
Christopher Gurnee
CC BY-SA 3.0
2015-06-07T10:51:56.080Z
2015-06-07T14:10:57.920Z
2015-06-07T14:10:57.920Z
Christopher Gurnee
<p>Essentially, I am seeking to know where in an HD wallet tree structure should hardened keys be used. For example:</p>

<ul>
<li>Shouldn't all child keys of the master extended key be hardened? </li>
<li>Should all extended public keys that are shared have the immediate parent key be a hardened key to ensure that a single compromised key doesn't compromise other keys?</li>
<li>Should the whole HD wallet tree structure use hardened keys except for the leaf node keys? </li>
</ul>

<bip32-hd-wallets>
Best Practices for hardened keys in HD wallets?
morsecoder
# Best Practices for hardened keys in HD wallets?

(Asked by: username_0 on 2015-06-07)

Essentially, I am seeking to know where in an HD wallet tree structure should hardened keys be used. For example:

* Shouldn't all child keys of the master extended key be hardened?
* Should all extended public keys that are shared have the immediate parent key be a hardened key to ensure that a single compromised key doesn't compromise other keys?
* Should the whole HD wallet tree structure use hardened keys except for the leaf node keys?

**Tags:** bip32-hd-wallets


---

## 2 answers

### Answer by username_2 on 2015-06-07. Score: 10 | Accepted answer

The simple (and I *believe* correct) answer is: use hardened keys everywhere except where a need for watching-only wallets is perceived, e.g. below the "account" level. A watching only-wallet in this scenario will be able to both create new addresses, and monitor the balance of an account.

Hence [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)'s path is:

```
m/44'/0'/account'/change/index

```

The clear result is that each account's xpub must be exported separately from a cold wall for import into a watching-only wallet.

Almost every wallet I've looked at uses this method (the exception being Wallet32 for Android prior to v0.2.5 released May 15 2014). Reference: [this bitcointalk post](https://bitcointalk.org/index.php?topic=1000544.msg10862297#msg10862297), which links to [this spreadsheet](https://onedrive.live.com/redir?resid=584F122BA17116EE%21313).

edited to add: Also of some relevance is the level at which an xpub is exported. Almost every wallet which supports xpub exports does so at the account level (same reference as above), which includes both the external and internal (change) chains of a single account. (The exception is MyCelium for iOS, however this is [considered a bug](https://bitcointalk.org/index.php?topic=965932.msg10564840#msg10564840) by the MyCelium devs.)

> **Comments:**
> **username_0**: Why isn't the change level of the BIP44 tree a hardened key? It only permits the stealing of the change addresses if an index key is revealed, I guess, but still why not?  
> **username_2**: @StephenM347 For the use-case of using an xpub to generate new receive addresses, I agree it would make sense to harden the change level. However I suspect the use-case of using an xpub to monitor the balance of an account is also very popular, and would require either a non-hardened change level, or the export of two xpubs which isn't very user-friendly nor easy to explain to newbies IMO.  

---

### Answer by username_1 on 2015-06-07. Score: 9

It is possible for a custom implementation use hardened keys for all the leaf keys to enhance security in case of a single private key leak. This scheme will be incompatible with the standard compliant wallets.

The BIP32 and BIP44 standards, use hardened keys up until the "account" level:

`m/44'/0'/account'`

but use non-hardened keys for the receive (a.k.a. external) and change (a.k.a. internal) addresses.

This is done to isolate the accounts and allow some flexibility:

* Use watch-only wallets by sharing the hardened xpub of the account.
* Derive new receive addresses without the need of the account private key (vs hardened derivation where the parent private key is required). This is a hassle because the account xpriv is usually encrypted and you need the user password every time.
* Store a single secret (the hardened xpriv) per account. Every time a transaction needs to be signed the correct child private key is derived on demand.

The security model of the BIP32/BIP44 is to use only one private key per account. The revealing of a non-hardened child private key equals to revealing of the account private key. If sharing of private keys is a requirement, it is preferable to create a new account and share the xpriv vs the non-hardened child private key of an existing account.


---

