Thanks much for that video reference, its a handy addition to BIP 0032 and helps flesh out some of the motivations behind the scheme. I am also creating a HW wallet prototype and am happily using BIP 0032 as my foundation for key generation. I appreciate the python implementation as it's a great check and reference.
One thing I've heard a bit about is BIP "0032.5" - could you comment on the motivations for this and what the key differences with BIP 0032 are - or maybe point me to a draft version of this that I can read? Thanks!
There is a lot of additional documentation for BIP32 in addition to the BIP itself:
For example,
http://www.youtube.com/watch?v=WcnMjkc31FsI'm disappointed that this is the first time I've heard your complaints. It has now been independently implemented by at least four parties. Your feedback sounds good though, do you have any proposed revised text? (And indeed, your understanding is correct).
The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property. In some use-cases it could easily cause a total loss. E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.
The text on that is a bit weaker because we added it later... we'd hoped for a while that there would be a way to remove that property but couldn't find one. The auditing behavior still exists, but works only in publicly derived chains.
Some client software may choose to only use public derivation, thus facilitating auditing. If they do they should probably avoid offering key export function for single private keys, simply because it has turned out to be really hard to educate users about the exposure.