1.9 Seems slower and loses alot of data?

[WesNz]

1.9 Seems to be slower and loses a lot of data Notice the Warning highlighted in bold.

VanitySearch1.9.exe -i FullBTC.txt -stop -o resultbtc.txt -t 0 -gpu -gpuId 0 [Loading input file 100.0%] [Building lookup16 100.0%] [Building lookup32 100.0%] Search: 9111116 addresses (Lookup size 65536,[93,2882]) [Compressed] Start Sat Mar 23 19:01:55 2019 Base Key:AE22A85EF9188EDAB8382FD1B5B6E45E0114C814A995DF32B722CF2B6636DB13 Number of CPU thread: 0 GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x128)

Warning, 133640 items lost Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m) ^C.672 MK/s (GPU 70.672 MK/s) (2^31.98) [P 0.00%][50.00% in 4.54541e+32y][0]

VanitySearch1.8.exe -i FullBTC.txt -stop -o resultbtc.txt -t 0 -gpu -gpuId 0 Start Sat Mar 23 19:04:18 2019 Search: 9111116 prefixes (Lookup size 64660) Base Key:7421184F7FB6F2C8D99484B1BCBACACEC4CC0658A0B112BED2A718B585E0BF73 Number of CPU thread: 0 GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x128)

Warning, 179762 items lost (try to search with less prefixes) 81.551 MK/s (GPU 81.551 MK/s) (2^34.93) [P 0.00%][50.00% in 3.93903e+32y][0]

[JeanLucPons]

Hello,

Yes when having a large list, you have to increase the number of maximum prefix found by the kernel using the -m option. I'm a bit surprised by this (Lookup size 65536,[93,2882]). The addresses in your list seem not uniformally distributed, you have a 32bit prefix which is much more used than others. Note that VanitySearch 1.9 does not check for duplicate addresses in the list. You have to ensure that all addresses are distinct.

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -gpu -m 131072 -i addr_10M.txt
[Loading input file 100.0%]
[Building lookup16 100.0%]
[Building lookup32 100.0%]
Search: 10000000 addresses (Lookup size 65536,[103,203]) [Compressed]
Start Wed Mar 20 09:13:29 2019
Base Key:328DBECB874367E08F6DB73CBE5A60C5688817CE93B5CF2A3582F02FE72B86E9
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 645 (3x192 cores) Grid(24x128)
17.694 MK/s (GPU 17.694 MK/s) (2^28.17) [P 0.00%][50.00% in 1.81548e+33y][0]

[WesNz]

Cool Thanks. Will test out later tonight, im surprised theirs duplicates addresses, will check that out have you found anything yet?

[WesNz]

Please explain this more :

The addresses in your list seem not uniformally distributed, you have a 32bit prefix which is much more used than others

[JeanLucPons]

May be there is no duplicate address in your list but the gap [93,2882] is quite surprising. It means that the lookup table is not uniformly filled. In my test I have used 10M distinct addresses randomly generated (as this should be) and I get a gap of [103,203] which is coherent.

No I do not search for address collisions. I plan to write an optimized Pollard rho for attacking ECDLP256 which will be much more efficient, this will obviously reduce the attack to reused addresses, but there is a lot of them on the chain.

[WesNz]

hmmm...will generate a new list and test that.

Sounds interesting! i see on the wiki, Richard Brent created a faster version of Pollard Rho

[prodnet]

When the optimized Pollard rho for attacking ECDLP256, will be ready ?

[JeanLucPons]

When the optimized Pollard rho for attacking ECDLP256, will be ready ?

I don't know, I have still few improvements to bring to VanitySearch.

[refresko1]

Hello friend, putting the VanitySearch to the test, I get the following message:

vanitysearch.exe -b -gpu -o general9.txt -i baseAdd6.txt [Loading input file 100.0%] VanitySearch v1.19 [Building lookup16 99.8%] [Building lookup32 100.0%] Search: 202467 prefixes (Lookup size 60223) [Compressed or Uncompressed] Start Mon Sep 6 15:14:52 2021 Base Key: 45F1AF1EFE0B031DDAD00BF1E7D68B9A38CFA0C8B649B09CBCC70349976725B0 Number of CPU thread: 3 GPU: GPU #0 NVIDIA GeForce 930MX (3x128 cores) Grid(24x128)

Warning, 34623463 items lost Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m) [15.83 Mkey/s][GPU 15.58 Mkey/s][Total 2^30.87][Prob 0.2%][50% in 10:46:14][Found 14]

Can you do me a favor and guide me a bit about the following:

1. (Warning, 34623463 items lost) How to avoid these losses?
2. the input -m is not clear to me, because, for example, if I put -m 10, it gives me a better performance, something like [25.39 Mkey / s], but if I leave that field empty, it throws me, like you can see, around [15.8 Mkey / s]. which should be then, the correct -m? Thank you