Quote from: NotATether on Today at 12:20:45 PM

Yes I've already consulted SLIP-0132 for my library at least 10 times (no offense).

My bad, I misunderstood.

Quote from: NotATether on Today at 12:20:45 PM

What's not clear to me is how they choose the version bit hex characters so that they align with the base58 characters, because as you know, 58 is not divisible by 16 so there will be some spillover into the 5th Base58 extended key byte.

The spillover is accounted for within the prefix bytes, so it doesn't spill out beyond this.

For example, if you take an xpub an decode to hex, your first 8 characters will be 0x0488B21E. This is the lower limit. Decrease by 1 to 0x0488B21D and your resulting string will start with "xpua". However, you can increase all the way up to 0x0488B224 and still have an "xpub". So any string which starts with "0x0488B21E" will always be "xpub", since even if every other byte is 0x00 or 0xFF, it still falls within the necessary range. Note that this works only because these strings are of fixed lengths. If you start adding or subtracting bytes, then the process fails.

So let's say I wanted to come up with a hex string which would have a prefix which encoded "oeLeo", followed by 14 bytes. I set my 14 bytes as all zeroes, and arrive at the following string:

Code:

046491a9c30000000000000000000000000000
oeLeo23QDxsqTT6RprgBHmFWP

If I increment my prefix by one, I get the following:

Code:

046491a9c40000000000000000000000000000
oeLeo3fWrUmEpNpaLkZLLXcHu

#

So I can use the prefix 0x046491a9c3, knowing that every possible value of the following 14 bytes still falls within the necessary range.