Best Practices for hardened keys in HD wallets?

Question

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?

Answer 1

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'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, which links to this spreadsheet.

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 by the MyCelium devs.)

Answer 2

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.