I have a large list of uncompressed addresses. Total number of 70 million addresses.
I have divided this list into 7 files. I expect VanitySearch to find a key to at least one address from the list. Of course, this is a cosmic sum in terms of chance! But theoretical is it possible? Or won't it work? That is, in terms of selecting a perfix for the full value consisting of 33-34 characters "Base58 (P2SH)".
List: "10 000 addr (P2SH)":1LAqmtxdjfsM2xsVVthsMUPsZ4Lw2X2sen
1JaS1LCj7m8BfJyexEqMVmSYs8RJhcRasy
1PTyMf9Z2TagnkMJVFNBEzR95QFqH99NQf
1NGL7KxXiYDcxxxhapukprgm2xm3D4MSL4
...
...
...
e.t.c
To increase the speed, maybe I need to cut addresses, leaving, for example, 10-12 characters for search?
Something like this:1LAqmtxdjf
1JaS1LCj7m
1PTyMf9Z2T
1NGL7KxXiY
...
...
...
e.t.c
It's not as much as the type of address you're searching for (bech32 does slightly more operations than the other two) or the length of your prefixes, the program stores all of the prefixes in an std::vector, so ignoring memory requirements (70,000,000*34 characters makes 238 megabytes to store the data itself so it's doable) it iterates over all of those addresses, vector is not exactly a fast container type for iteration so you'll be spending too much time waiting for a key to be tried for all 70 million addresses to have a realistic chance of finding a match.
This can be fixed by storing all the prefixes in a bloom filter instead of a vector, but then again, that's not exactly the purpose of VanitySearch.
What do you mean? VanitySearch can't take a list of addresses, only a list of prefixes, and adding more of those will slow the program down.
It does and will take a list of full addresses. I think Jean Luc said it was better to put in full, if you were looking for a full address.
There are special codepaths taken when VanitySearch detects a full address that check the ripemd160 hash for a match instead of a lengthy
strncmp.
