I discovered a bug in the interface code that I fixed today. If anyone is using it, I strongly recommend that they get the fixed version.
Here is a bit more detail for those interested. In BIP0032, one can use extended private keys to derive two kinds of children. One uses "private derivation" and the other uses "public derivation". "private derivation" is used if the 31'st bit is set to 1. The bug was that I set the 32'nd bit to 1 instead of the 31'st. As a consequence, "public derivation" was always being used. As an example, the buggy version did this:
Ask for extended private key of private child 1 of a certain extended private key (all in hex):
BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN
Ask for extended private key of public child 1 of the extended private key:
BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN
The results are the same, while they should be different.
Retrying the operations with the corrected version, we get:
81JYCmcp9JmKYabjEBpcm3SBoLVfFXEkRRneF4jXgjp3
9EmGBeqvxz6cRN2TRFTPo7ipR4Mx4qthBrMXSbszRtyU
./bip0032sbclexec ckd Ao6S99sRJ5H2HHiQD5yAwk1rLFCjpbV4mNAvLr2LpkyY 7PXDSih7ZzE1bbomW6CwGpSwAnSgkeKwZXe4x9D6XRnj 1
BbGJWhs4RTX4JoGYcnWZDeGVJ1YRUcFnTZUKz4Aoc8dB
7MCsRVh3myvssjZAc4zkS9nyGx1Sm7a99FpQUyi6W4MN
Now they're different.