This is probably why the developer did not add a search for a range of keys. so that it would be impossible to track the correctness of the search for full addresses, and not vanity prefixes.

He didn't add it probably because, as time has shown - he doesn't devote much time to this project ... there is no other reasonable explanation. Regardless of whether the range is random or whether I can determine it myself - the fact of proper operation is impossible to investigate, and the randomness of the range is only an additional difficulty to determine this fact. The fact of the first of the above-mentioned causes that VanitySearch is only suitable for use if you want to find yourself an individual and short prefix, and is not suitable for use in any challenge or for any profitable purposes, because if you are looking for a difficult prefix to find takes XXX days - you are not sure if he will be found. I have a modified version of VanitySearch in which I can set this range and interestingly - recently trying to check if everything works correctly in different ways - it turned out that changing the value of "max found" (-m) causes that in the same search range (on short four-character prefixes) - increasing this value causes that there are completely different prefixes ... So what is the miracle? The range is the same, and the keys and prefixes are different.

Enjoy the stoichiometry/shotgun methods.

Im out BTW , Vanitypool is basically done. Yall have at it 14 problems left.

13

BTW. My question to the author or someone who has knowledge of the subject:

As described by VanitySearch's arguments:

-m: Specify maximun number of prefixes found by each kernel call

- What is the default value of this parameter?

- What to consider when setting it up? (RAM, amount of core ...?)

- What are the disadvantages of increasing this parameter?

...and finally:

- How to unitize it?

I can set this parameter to the value of 1920000000 - then I will get (scanning the same keyspace range) completely different results [also correct]!

So I dare say that if we change the value, we get different results than without this value - then with difficult prefixes the rule also works: either it will be found or it will get lost along the way for some reason