edit Fails as it doesn't adequately protect the secret master key from two collusions. See the comments.
http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/As described in the article above (go down to the section “An Understated Problem”), deterministic wallets have a flaw with a solution best described in the following quote:
The idea is that if you give the auditor the watch only wallet, he could conspire with one of the holders of the private keys below it to create the master private key and run away with all the money.
M = master public key
m = master private key
m/ = CEO holds it
M/ = Auditor holds it. With it, they can view all company funds, but not spend.
m/m1 = Department A head holds it, and can generate further chains with it.
m/m2 = Department B head holds it, and can generate further chains with it.
m/m3 = Department C head holds it, and can generate further chains with it.
combining M/ with m/mx would give me m/ ... so an auditor would have to conspire with one corrupt department head to run away with the company's entire finances.
With the solution provided says that the CEO would make
m1/
m2/
m3/
Then
Dept A:
m1/m1
m2/m1
m3/m1
Dept B:
m1/m2
m2/m2
m3/m2
Dept C:
m1/m3
m2/m3
m3/m3
Each dept using the three public keys generated by those chains to generate deterministic 2of3 chains.
The Auditor would ONLY receive:
M1/
Then they could check the blockchain for redeemscripts that included
M1/M1
M1/M2
M1/M3
Then they would know how much money each department SPENT without being able to collude to get 2 private keys.
Downside: They could only find SPENT funds, as the redeemscript is only revealed on the blockchain when funds are spent from the multi-sig address.
imo, the best way to do an audit for business would be to use a dual-key Stealth Address, and give the scan_privkey to the auditor... but this is a topic slightly unrelated to BIP32.
You could set up so your company's stealth addresses are generate on a per-department basis, but that all scan_keypairs are generated by a separate BIP32 chain.
Give that master private key to the auditor, as that keypair is only used to generate shared secrets to discover funds, not to spend it.
I think I have a solution that doesn’t depend on 2 of 3 keys as described above.
The owner of the Master Private Key (call it “a”) generates another secret from that (call it “r”) where r = H(a), a hash of “a”.
He passes the public sides, A = [a]Q and R = [r]Q, to the auditor and combined, they become the Master Public Key.
The owner generates the “n”th private key as follows:
sn = H(n,A)
tn = H(n,R)
rn = (r)(tn) the product of the two private parts modulo a large prime. Note, this remains secret to the owner by virtue of keeping “r” private.
xn = (sn)a + (rn) where xn becomes the “n”th private key.
The idea is that “rn” will not be known to the auditor or to the holder of “xn” as we will see in a second. It therefore “covers” the Master Private Key in case of collusion between the auditor and the holder of “xn”.
The Auditor:
The auditor knows A, R, and n (Furthermore, he knows “xn” for any and all “n” due to collusion.)
He can generate the “n”th public key as follows:
sn = H(n,A)
tn = H(n,R)
Rn = [tn]R the public part of the private “rn” which he doesn’t know since he doesn’t know “r”.
Xn = [sn]A + Rn where Xn is the public side of “xn”, the “n”th private key.
Knowing “xn” does not give him “a” since “a” is protected by the unknown “rn” in the equation xn = (sn)a + (rn)
edit Fails as it doesn't adequately protect the secret master key from two collusions. See the comments.
