Hi folks, I have started to notice and report an overflow of the depth of extended keys (as described in BIP32) and some confusion regarding the depth came up. On one hand, the depth is, I’d say indirectly, limited to the range [0 , 255] due to the serialization into a single byte. On the other hand, I don’t see an inherent technical reason(s) that would prevent deriving even lower keys (with depth 255+).
The list of libraries, where I see the depth overflowing is increasing: https://github.com/libbitcoin/libbitcoin-system/pull/1624, https://github.com/bitcoinj/bitcoinj/pull/3693, https://github.com/tyler-smith/go-bip32/issues/27, https://github.com/MetacoSA/NBitcoin/issues/1260, https://github.com/piotrnar/gocoin/issues/71,…
In bitcoin repository, the overflow is caught here (and also here) and there is also a test case for it. But the derivation paths themselves aren’t restricted in the size. Due to the variety of implementations and libraries APIs’ for the derivation paths and key derivation (priv -> priv, priv -> pub, pub -> pub), there are also a few different ways how to possibly hit the overflow.
Keys that overflow could be hiding coins (as they would appear to live at different levels), but the valid parents are likely still identifiable via the fingerprints. (Possibly, in some edge-cases, overflown keys could be invalid in such a way that the coins would get locked.) I am not familiar with how the depth is used later on, e.g., after key deserialization, and if it could cause other issues.
Are there any legitimate reasons to allow longer paths and keys with depth > 255? Or shall any such overflow be considered a bug? Not sure, if I can tag Pieter Wuille, to get his thoughts regarding the depth validity and if there is more to it.