Hi,
The time here is mainly spent in writing the output file. By searching 1*, all generated addresses will match and will be output to the file.

"Items lost" refers to items found by the GPU that match the lookup table. It is not only  link to the number of prefixes your search, but also to the number of threads.
When you have a lookup size of 65536, each GPU thread will return 6*1024 items.
With -g 88,128 and a lookup size of 64660, the number of items found by the GPU is (in average) 6*1024*88*128*64660/65536 = 68 280 960‬ and cannot exceed 6*1024*88*128*65536.
This has to be improved.

OK I see, I have to work on that issue, in some configuration, the memory exchange between GPU and CPU is not very well adapted.


OK I'll add this.


Total is the total number of key checked.
Prob is the probability to found at least 1 prefrix after Total tries (so, where you are)  according to the difficulty.
According also to key rate, the third field [99% in 00:00:00] estimate when you will reach the displayed probability of having at least 1 item found.

The difficulty calculation of case insensitive search is trickly and the program may give a bad approximation.

I just added : printf("%d:%s \n",i,tmp); at line 575


It outputs correct combinations, note that the lookup size printed is the number of the 16bit hash entries of possible prefixes (not the total number of combination):

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -c -stop 1abc
VanitySearch v1.17
0:1abc
1:1Abc
2:1aBc
3:1ABc
4:1abC
5:1AbC
6:1aBC
7:1ABC
Difficulty: 19627
Search: 1abc [Compressed, Case unsensitive] (Lookup size 6)
Start Thu Feb  6 13:16:48 2020
Base Key: B0384C0C93590167CF8AE3FD40E06F9065008F9DF2F2D305A21F84963467C3A
Number of CPU thread: 8

PubAddress: 1ABCE4631tuX4TCSqwRARpeJhouCkCHam5
Priv (WIF): p2pkh:L3eTmtQqjPZnBppJHi6L5c6jeLLu3yYaPQtXUFWg6tR8WbDfD4Gg
Priv (HEX): 0xBFC1EC9B163A2B5F10A1153490E222F8B8AEBAD2E0FEABACB5173CBDB6FC4C34

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -c -stop 1abcd
VanitySearch v1.17
0:1abcd
1:1Abcd
2:1aBcd
3:1ABcd
4:1abCd
5:1AbCd
6:1aBCd
7:1ABCd
8:1abcD
9:1AbcD
10:1aBcD
11:1ABcD
12:1abCD
13:1AbCD
14:1aBCD
15:1ABCD
Difficulty: 569190
Search: 1abcd [Compressed, Case unsensitive] (Lookup size
Start Thu Feb  6 13:23:16 2020
Base Key: 15FC12001ECE83FC425FC81BB34F5457138A92020CFB26FF510A958AC689C474
Number of CPU thread: 8

PubAddress: 1AbcD2q4EHSgP6KBynmyycxCSa5jpKwMiG
Priv (WIF): p2pkh:L3zpLCR5HeN2gsJgd6CeEY3vQJGLCpFVMzYZqgZtaMTcHeEfRkxv
Priv (HEX): 0xCA3A8604599F8FAD61A651B812CB44224864F17F298AB49E92183F4196E43E06

It creates a lookup table with all "pre-build" targets. VanitySearch.cpp:94.
I'm a bit surprise of your performance using -c. I tried a file with 11 prefixes and a lookup size similar to your and
It goes from 223MKeys to 169MKeys (compressed) and 83MKeys to 62MKeys (compressed + uncompressed).

OK, I will try to install CUDA 10.2 and see what's wrong with it.
VanitySearch.sln is in the git repo:
https://github.com/JeanLucPons/VanitySearch/blob/master/VanitySearch.sln

It seems that there is some problems with recent release of CUDA. I will also try to have a look at this. Thanks for you report.

The sln file is included in the repository.
Start by cloning the repository (you need git to be installed)
git clone https://github.com/JeanLucPons/VanitySearch.git
Visual Studio community edition is freely available from the Microsoft Website (I don't know if 2017 can still be download but it should work also with 2019, if it is not working with 2019 then I'll try to make a path).
Then launch visual studio and open the sln file.

The only informations available are there:
https://github.com/JeanLucPons/VanitySearch/blob/master/README.md
If you need furthers details, you can ask here.

Hi,


I optimized a bit the GPU code for compressed key, GPU/GPUHash.h and GPU/GPUCompute.h.
More or less, I factored a bit the HASH calculation of symmetric keys and I added some _synchthreads() in order to try to keep a best synchronization between threads. This gives me a ~5% performance increase on my hardware.


VanitySearch supports only CUDA.


You mean 1.16 gives  6800-7000Mkeys/s and 1.17  42000-43000Mkeys/s ?
Did you wait a bit in order to stabilize the key rate measurement ?
Could you give me your grid size(s) ?

Hi there,

A new release is available (1.17):
-Slight performance increase (compressed key only) GPU
-Fixed counting bug for large grid size

Thanks to test it
Have fun

lol 
What a grid size !

Seems an integer overflow.

If you manage to compile, could you try to change:

Vanity.cpp: 1565
      counters[thId] += 6 * STEP_SIZE * nbThread; // Point +  endo1 + endo2 + symetrics
by
      counters[thId] += 6ULL * STEP_SIZE * nbThread; // Point +  endo1 + endo2 + symetrics

This should be enough.

There is only few changes since the 1.14.
Does the 1.15 works also ?
I can imagine that a bug has been introduced with the dynamic grid size in 1.16 but in 1.15 there is only a change that concern P2SH and BECH32 addresses...

You can show changes by looking there:
https://github.com/JeanLucPons/VanitySearch/releases

I think it will work but effectively you may need to install specific CUDA software.

I don't kwon, I'm using ubuntu 18.04.2 LTS with an old quadro and it is working well except that I had to repatch again the cuda driver in order to make it work (quite a nightmare) following a kernel update. Kernel maintainers has again beautified the code breaking the backward compatibility by removing and changing some kernel functions. pfff....

By default VanitySearch takes 8*(MP number),128 for the grid size.
You can set it up using -g (you need the last release for setting 2D grid size)
ex:
VanitySearch.exe -t 0 -gpu -g 48,256 1TestMe (with a single GPU)
VanitySearch.exe -t 0 -gpu -gpuId 0,1 -g 48,256,64,512 1TestMe (with 2 GPU)

It is good to take the first value as a multiple of the multiprocessor count and the second as a power of 2.
The number of multiprocessor is given with:

VanitySearch.exe -l
GPU #0 GeForce GTX 645 (3x192 cores) (Cap 3.0) (1024.0 MB) (Multiple host threads)

Here 3 is the number of multiprocessor.

If you are using a GPU, play a bit with the -g option in order to adjust your grid size for best performance.

Yes the input file is just a list of prefix to search.
Ex:

People who use hundreds (even millions) of entries likely search for full addresses.

Hi,
Did you try older version ?
I do not manage to reproduce the issue on my hardware.

I fully agree and the full source code of VanitySearch is public. Anybody can compile it, the code is documented, you can read it.

The base key does not alter performance. VanitySearch choose a secure random base key (if no seed specified) only once when it starts. Then private keys are incremented, 6 addresses are calculated and prefix are checked. The process is simple. You have the possibility to choose new random base keys every certain number of key using -r, but it is slower and useless because it requires extra EC mult. It does not improve the probability to find a match.

Yes keyspace START:END+Count , but i don't knwo when I will do that.


VanitySearch may be less efficient for short prefixes (less than 3 char) than vanitygen. I presume it is because VanitySearch use a 16bit lookup on the hash160 to speedup the search not because keys are not random.