KeyPath.TryParse accepts invalid paths

[mf-16]

The KeyPath.TryParse method in NBitcoin currently accepts certain inputs that I believe should not be accepted:

1. Multiple Consecutive Slashes: Paths like /1/// are accepted due to the removal of empty values when splitting the path by '/'.

2. Incorrect Handling of -0: Paths such as /-0/-0/-0 are incorrectly accepted. This happens because KeyPath.TryParse internally calls uint.Parse(), which treats -0 as a valid unsigned integer (0).

[quapka]

Nice catch @mf-16. My few cents.

1. Don't wanna be seing "ghosts", but I can imagine the silent removal of consecutive slashed could lead to a key-reuse and thus an (likely, unexpected) address reuse, because:

key.Derive(KeyPath.Parse("/////////////")) == key // True

If more complex paths are entered manually, double slashes might also get overlooked. IMO, key handling should be strict and cautious rather than relaxed and opportunistic.

2. The -0 within a path is in conflict with how key-origin is described in BIP380, see the test vectors, in particular [deadbeef/-0/-0/-0]0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600. Here, I think the original BIP32 underspecified the key indices and later, BIP380 continued with simply referring to NUM without any serialization format.

[quapka]

Many other values are parseable as uints. While I don't see a direct problem with that, it can cause two Output Script Descriptors that result in the same key and thus scripts to have different checksums.

KeyPath.Parse("-0 ");
KeyPath.Parse("+1 ");
KeyPath.Parse(" 1 ");
KeyPath.Parse(" 0001 ");
KeyPath.Parse(" +0001 ");

[quapka]

I've done some grepping using Github search for the usage of repeated slashes, but so far found no matches. Similarly, no hits for the units.