Understanding BIP 32: private derivation and public keys

[imrehg]

I was checking the BIP32 description at https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki and playing with pycoin which does implement it, but some of the things are not totally clear to me.

1) In the document's notation m/i' means the ith first level wallet using private derivation using the private master node key (e.g. "Per-office balances"). M means public master node key (e.g. "Audits"). What does M/i' mean then? Isn't that true that primed wallets cannot be derived from public keys so it cannot be "ith first level wallet using private derivation using the public master node key"? Or would it my any chance mean "the public key of ith first level wallet using private derivation using the public master node key" (ie. the public counterpart of m/i')? But then I don't quite get the the logic of the notation.

2) If the primed lines cannot be derived from public keys, is it true that M alone cannot be used for complete auditing? If so, then every primed node has to share its public key with the auditor for access, and whoever holds M can never be sure that the holder of m didn't create hidden wallets.

3) Based on these, what would be actual the derivation of M/i'/0 (e.g. "Unsecure money receiver" & "Recurrent business-to-business transactions")?

My guess is that some of these issues stem from the particular weakness outlined there:

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

but then e.g. how would M / Audits example be ever be correct? Can it be that parts of the document are not in line with each other after some changes in the ideas/notes/text?

[Sarchar]

I'm saddened that nobody has responded yet. I just put up http://bip32.org/ and I, too, had this exact concern while implementing it.  I don't know how to interpret M/i'.  In fact, it seems to me that you don't need private key derivation at all, just the ability to derive new private keys (from public key derivation) seems sufficient.

[WeMeetAgain]

I don't know how to interpret M/i'.

I'd say its trying to mean the public key of m/i'.

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

It looks like its assuming that you are, by default, protecting the master private key by always making the first generation of children through private derivation.

2) If the primed lines cannot be derived from public keys, is it true that M alone cannot be used for complete auditing? If so, then every primed node has to share its public key with the auditor for access, and whoever holds M can never be sure that the holder of m didn't create hidden wallets

Yes.

Can it be that parts of the document are not in line with each other after some changes in the ideas/notes/text?

That's what it looks like to me.

[Sarchar]

I don't know how to interpret M/i'.

I'd say its trying to mean the public key of m/i'.

OK, this makes sense.  The big/little M at the beginning describes whether the goal is to obtain/use/share the public or private extended keys in the result?

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

It looks like its assuming that you are, by default, protecting the master private key by always making the first generation of children through private derivation.

Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation.  As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard.

[Sarchar]

Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation.  As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard.

Nevermind - I've figured it out. Chain codes aren't private, so even if someone has M (the public key of m), they cannot derive m/i'.  This is important: it means that even with knowledge of the master public key, you cannot see any privately derived keys, public or private.