Why the normal mode exist in BIP32

0

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?

Carpemer

Posted 2019-01-24T12:00:41.837

Reputation: 117

Answers

2

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)

James C.

Posted 2019-01-24T12:00:41.837

Reputation: 2 183

actually you would provide the account level xpub to the web app i.e. m/44'/0'/0'. – Abdussamad – 2019-01-24T13:13:37.190

No xpub children can be derived from M/44’/0’/0’ – James C. – 2019-01-24T13:23:52.907

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 – 2019-01-24T13:49:04.490

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? https://teachbitcoin.io/presentations/wallets.html#/7

– James C. – 2019-01-24T13:52:11.660

@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 – 2019-01-24T14:17:52.073

Sorry. Yes you are right A hardened xpub has no parent xpub key. I will amend this in the answer. – James C. – 2019-01-24T14:24:18.257

Asked: 2019-01-24T12:00:41.837

Viewed: 43 times

Active: 2019-01-24T14:29:23.940