What I'm saying is that when filtering for a match, the first thing that happens is filtering the H160 bits.

However, depending on the specific base58 prefix, that filter will return false positives, in a less or greater amount.

Explicitly for the "1PWo3JeB9jrGw" prefix (this calculation and the results will differ for every possible prefix):

- I gave the minimum possible H160 value that converts to a valid address having this b58 prefix
- I gave the maximum H160 value as well

The script is too complex, so it's irrelevant. What matters is that these are the min/max bounds for any H160 value that will correctly encode into a correct and valid desired base59 address.

So, once we have this (max - min + 1) total unique H160 values, than when we hash ANY value, and it falls into this interval, then it's a 100% base58 match.

Since H160 is 160 bits, then the probability to ever have a match becomes:

(max - min + 1) / 2**60

for every time we do a hash.

HOWEVER, people will most likely want to fast-filter the H160 itself, right?

So, counting the common front bits between the minH160 and amxH160, we have 67 matching bits.

This means:

- if a H160 has those 67 bits matched, then it MIGHT also lie between the min and max

but... that is not a guarantee. There will ALWAYS be more H160 matches than the number of actual base58 matches, and this is why:

- the minH160 has 67 common bits, followed by a 0 bit, and then 92 ANY other bits
- the maxH160 has 67 common bits, followed by a 1, and then some ANY other bits

Extreme example to understand the problem:

minH = <67 bits> 0 <1111111....1>
maxH = <67 bits> 1 <0000........0>

So, in this case we have only 2 valid H160 values that yield some prefix.

However, there are 2**93 H160 actual hashes that match the first 67 bits.

Ratio between H160 matches and base58 matches: 1 / 2**92.

Hope that clears it. Of course the example isn't practical, but the ratio can go up to 3 or 4 depending on oow the base58 prefix's min/max H160 end up looking.