HDKey derive returns Invalid index about scure-bip32

[paulmillr]

I think the best way to move forward would be to create deriveUnsafe, which would follow the cross-library-compatible behavior.

[paulmillr]

You have invalid index, obviously.

The specification clearly says indexes over 2^31-1 are banned. Your numbers are bigger than that.

Bip32 package does not implement spec correctly. They could change their behavior later and your code would stop running.

[junderw]

From BIP32 spec:

Each extended key has 2^31 normal child keys, and 2^31 hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 2^31-1. The hardened child keys use indices 2^31 through 2^32-1. To ease notation for hardened key indices, a number iH represents i+2^31.

Also, the path syntax is only remotely mentioned here, the convention of whether to use m or M for the root, whether m should be used when trying to derive from a non-root state, whether ' or H or h should be used, whether they are optional etc. are noticeably not specified in BIP32.

This is not an issue of spec, but rather, an issue of interpretation of "what is the norm among other implementations?" since the syntax is not specified.

---

That said, I don't care either way, but changing our interpretation from m/2147483648 and m/0' are parsed to mean the exact same thing. into m/2147483648 throws an error because it is not within 0 <= N <= 2^31-1 is a breaking change, so I would need to see whether a majority of implementations in other languages etc. parse in that way.

If it is the case that m/2147483648 is an Error and not a hardened derive in a large majority of BIP32 implementations across languages, I would be willing to change to match.

[junderw]

If the spec had said "a string path representation of i+2^31 MUST be represented as iH" then it would be spec... but also it would mean i' (apostrophe style hardened notation) would be non-spec.

There have been instances of BIPs being modified to match convention when ambiguous in the past, so maybe this could be proposed as a clarification modification to BIP32.

@Dolu89 @paulmillr Thanks for bringing this up. Please let me know if either of you want to move forward with proposing a change to BIP32, or if anyone wants to take the time to look up the behavior of other libraries.

[junderw]

pathSuffix.join('/')

Can also be changed to

Array.from(pathSuffix).map(n => n & 2**31 ? `${n & 2**31-1}'` : `${n}`).join('/')

Which should work with either implementation.

Edit: Also this, which circumvents the string parsing entirely.

[138+2**31].concat(Array.from(pathSuffix)).reduce((hd, idx) => hd.deriveChild(idx), root);

[paulmillr]

sigh another disadvantage of bip32 specification. It's too complex: some different solution could achieve similar functionality in a radically simplified fashion.

Adjusting scure's behavior to match other libraries can be beneficial in this case. Keeping the current behavior as-is could also be fine, since it asks users to be precise; also keeping it as-is makes audit results more relevant than if we change it.