The testsuite is quite likely to generate false positives, because it creates a lot of hashes and the search space is relatively small.
The hashes are base64-encoded, so that should give an alphabet of 64 characters, which with a hashlength of 4 characters gives a hash space of 64^4. However, as hashes are checked in a case-insensitive manner, the effective alphabet has only 38 characters for a hash space of 38^4 (approx. 2^21).
The test suites creates 63^2 random addresses, and then changes each single letter in (the local part of) each address, thus creating 63^3 hashes. This is 12% (63^3 / 38^4) of the total hash space, so there's about a one-in-nine chance that the testsuite will give a false positive.
Suggested fix: increase hash length in test suite using e.g. srs_set_hashlength(srs, 16).
The testsuite is quite likely to generate false positives, because it creates a lot of hashes and the search space is relatively small.
The hashes are base64-encoded, so that should give an alphabet of 64 characters, which with a hashlength of 4 characters gives a hash space of 64^4. However, as hashes are checked in a case-insensitive manner, the effective alphabet has only 38 characters for a hash space of 38^4 (approx. 2^21).
The test suites creates 63^2 random addresses, and then changes each single letter in (the local part of) each address, thus creating 63^3 hashes. This is 12% (63^3 / 38^4) of the total hash space, so there's about a one-in-nine chance that the testsuite will give a false positive.
Suggested fix: increase hash length in test suite using e.g.
srs_set_hashlength(srs, 16).I just hit this with these addresses
The mutated address has an hash of
wjxZ, which is equal to that of the forward SRS address (except for the case difference).