1

Suppose the BIP32 normal deviation is not safe enough.

Suppose the xpub is deployed on the server, we assume it is public, then the leak of any derived private key is the leak of the parent private key, which means all the derived private and public key could be calculated.

Why this mode still exists, instead of using hardened mode as the default for all derive operation?

The second Point I hope to clarify here, is that if there is only one bit in the path is hardened mode, say m/0'/0/0, then the derived address is a 'hardened' address (parent private key can not be derived from parent xpub + child private key), or we need every bit in the operation is in hardened mode?

The last question is what the "layer" means exactly in BIP32? (A) Per my understanding, if we have a master private key, any path (m/0/0, m/0'/0, m/1',m/1/2/3/) we used to derive the sub private key are the child address. If we use child address to derive again with any path (m/0/0, m/0'/1), then that is the second layer's address. or (B) if we have a master private key, use path (m/0') is the first layer. use path (m/0'/0) is the second layer?

What is the background and consideration for this design?

Improve this question

1 Answer 1

Reset to default
3

Hardened extended private keys break the extended public key derivation path, which is why unhardened key generation is still valuable.

I can provide an xpub key M/44’/0’/0’ to a webapp, which can then create fresh addresses without having access to any private keys.

For example, the following receiving keys (and related addresses) can be derived from M/44’/0’/0’

  1. M/44’/0’/0’/0/0
  2. M/44’/0’/0’/0/1
  3. M/44’/0’/0’/0/2

or following change keys (and addresses)

  1. M/44’/0’/0’/1/0
  2. M/44’/0’/0’/1/1
  3. M/44’/0’/0’/1/2

The backend which has m/44’/0’/0’ can derive all private xpriv keys to spend funds sent to addresses above, thereby never exposing any privatekeys to the userfacing webapp. However, a xpub key m/44’/0’ (hardened or not) cannot derive a hardened child xpub key m/44’/0’/0’.

The leak of a child private key does not expose parent keys. This would also require the xpub of the parent key pair and child index. Hardening prevents this exposure scenario. So for BIP44 the tradeoff is made at the account level (m/44’/0’/0’/) where the account parents are hardened but subsequent receiving and change keys are not.

Edited: Correction from Abdussamad (See comments)

Improve this answer
6
  • actually you would provide the account level xpub to the web app i.e. m/44'/0'/0'.
    – Abdussamad
    Jan 24, 2019 at 13:13
  • No xpub children can be derived from M/44’/0’/0’
    – James C.
    Jan 24, 2019 at 13:23
  • Sorry for the confusing, because the xpub is supposed to deploy on the server, that is why I assume xpub is public. (updated the question) Do you mean if the last bit, for example (M/44’/0’/0’/0), is in normal mode, then it could be used to generate the derived address? Beside, I am a little bit confused about the second round of derive. If the web app get the xpub generated by M/44’/0’/0’/0, you mean the app use 0 as the new new path to get M/44’/0’/0’/0/0?
    – Carpemer
    Jan 24, 2019 at 13:49
  • 1
    Yes correct. When the last derivation index is not hardened, it can derive child public keys. I have an entire chapter on hd Keys, including parent key exposure, which may be helpful? teachbitcoin.io/presentations/wallets.html#/7
    – James C.
    Jan 24, 2019 at 13:52
  • @JamesC.you can derive non-hardened children from a hardened xpub. in fact that's why there's no hardening beyond the account level. you share the account xpub and create watch only wallets that can generate both external and internal chains under that account level.
    – Abdussamad
    Jan 24, 2019 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.