I want to stress that BIP32 isn't final yet, so please don't release code that implements it.
If there is need to make changes still, I really want to avoid several different revisions in the wild.
I'll post test vectors in the BIP document as soon as I feel confident things won't change anymore.
What's the timeframe on that? What is the criteria we're using to say it's final? I ask, because I've been hitting my new wallet format pretty hard, and I realize you're right -- if there's any chance BIP32 will change, then it could cause a mess for any users that already created wallets with the old ones.
Related: I actually ran into this in my first couple releases of Armory where I was still tweaking the wallet algorithm (this was 12+ months ago). I created "Wallet ID" strings that are 6 bytes long, used to distinguish wallets. The problem was, different wallet versions using the same seed were producing the same ID because it was only based on the public key of the root. I later decided it should be based on both the root public key
and the first derived key (in this case, it would be root public key, M, and M/0 public key). This way, the ID is encoding the root
and the chaining algorithm at the same time. It seems like a small thing, but as a developer playing with different wallet versions, it made it very easy to determine whether a wallet was generated with the same chaining algorithm you are expecting.
By the way, for reference, my BIP 32 implementation in C++ using Crypto++ is
here. Rather, that's the ChildKeyDeriv function, which is the core of BIP32. There's some test vectors there, too, but I won't make it too obvious how to find them, since we aren't promoting it yet