I guess my "issue" with the above math, taking the 10 character prefix, as an example:
If you ran this:
min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()
for every possible 10 character prefix, from:
min = base58.b58decode('1111111111111111111111111111111111').hex()
max = base58.b58decode('11111111111zzzzzzzzzzzzzzzzzzzzzzz').hex()
through:
min = base58.b58decode('1zzzzzzzzzz11111111111111111111111').hex()
max = base58.b58decode('1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz').hex()
and each one spits out "425", then that is more than 2.5 times larger than the 66 bit range. 58^10 x 425 / 2^66 = 2.48
I know this is all hypotheticals, but I struggle with the above formula because of how much larger it actually is versus a 66 bit range.
Maybe I will run some smaller, but quicker tests, just to see how close each formula is.
You are totally correct that 58**10 * 425 > 2**66, but I fail to understand why is this important?
Yes, every base58 char can have values (0, 57), but if you do log(2**160, 58) you will see that it is not an exact integer (and we can't have addresses with a fractional length, right?), so your formula needs to be adjusted so that those "10 characters prefix" means "10 out of an average 27.3132 characters", and/or the base is also lower than 58, since any given character of an address encodes on average less than 58 values (so that x**addr_len == 2**160).
Anyway, this only shows further how useless it is to use the prefix as any sort of reliable attack, instead of the RIPEMD hash directly.