Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation.