Quote from: Crowex on January 08, 2015, 04:50:48 PM

How can you give someone in a department their own set of master keys so that they can derive their own private keys without giving them the ability to derive the actual master keys?

You're right. That was a mistake on my part. Sorry about that. (Unfortunately, anyone who ever reads this thread forever after now needs to skim through that piece of stupidity. That's the problem with fora. Grr...)

What I said works if you reveal only the public keys for M/"0", M/"1", etc but not the private keys m/"0", m/"1". If you want a multi-level hierarchy in the treasurer use case (in which everyone in the corporate ladder gets a private key) with this wallet then I see two options:

[This point edited a bit after posting.] If the master public keys are public knowledge anyway then you could just implement a "flat" or "simulated" hierarchy, meaning that the key m/x/y/z is a linear combination of the original n master keys d₁,...,d_n where the coefficients are derived from the hash of (x,y,z). Note that a total of no more than n-1 private keys can be revealed from anywhere in the hierarchy. That might seem bad but it's still an improvement on BIP32, where any one (non-hardened) private key from anywhere in the hierarchy can be combined with the master public key to break the wallet.
If you really want to give each child a,b,c,... ability to reveal up to n_a,n_b,n_c,... private keys then you need at least 1+n_a+n_b+n_c+... master private keys. This isn't a problem if you're the top-level admin because you can generate the private keys deterministically. But if you're an auditor (who is only allowed to know the master public keys and needs to store them explicitly) then you could run into an exponential blow-up of public key size: if you want each node in a k-ary tree of depth d to be able to reveal up to n keys then you need something like (kn)^O(d) master keys.