Panics due to depth overflow when deriving `ExtendedSpendingKey` on 256 levels and greater

[quapka]

Hi,
When researching depth overflow for BIP32 keys I've noticed that Zcash's child derivation can also overflow the depth. Consider the following example that panics:

diff --git a/src/zip32.rs b/src/zip32.rs
index 93b1cf5..247f1e4 100644
--- a/src/zip32.rs
+++ b/src/zip32.rs
@@ -244,6 +244,18 @@ mod tests {
         assert!(xsk_5.is_ok());
     }

+    #[test]
+    fn derive_child_depth_overflows() {
+        let seed = [0; 32];
+        let mut xsk = ExtendedSpendingKey::master(&seed).unwrap();
+
+        let i_5 = ChildIndex::hardened(5);
+        for _ in 0..256 {
+            xsk = xsk.derive_child(i_5).unwrap();
+        }
+
+    }
+
     #[test]
     fn path() {
         let seed = [0; 32];

In case of Bitcoin the issue is then that the serialized keys overflow (the depth has to fit into a single byte). For Zcash, apart from the panic, I am not sure about other possible issues.

[quapka]

I'm not familiar enough with Zcash, in case of Bitcoin both xprv and xpub tend to be affected. Also there are various derivation paths, e.g., deriving the child xpub directly from xprv could silently overflow. Since Zcash keys work differently, I haven't found similar issues here. Regex searching the repository for /\+\s+1/ shows only the above example.