VanitySearch (Yet another address prefix finder)

[cryptoroy]

I tried with 100003 addresses and it works on my hardware. (also with -b)

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -gpu -i inputfull.txt
[Loading input file 100.0%]
VanitySearch v1.16
[Building lookup16 100.0%]
[Building lookup32 100.0%]
Search: 100003 addresses (Lookup size 51290,[1,9]) [Compressed]
Start Tue Jan  7 14:14:29 2020
Base Key: 1DC7F473D7623CA1A39DDB131AAB773BCA7242CEDD8481E355B7EE4F18964B02
Number of CPU thread: 7
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
[229.56 Mkey/s][GPU 212.17 Mkey/s][Total 2^30.78][Prob 0.0%][50% in 1.39935e+32y][Found 0]

I will try with 2 GPU to see if something is wrong there...


There is no limitation to find the key of an address, only the time needed

Thank you, I'm immortal ))

[1715636562]

1715636562

[1715636562]

1715636562

[1715636562]

1715636562

[1715636562]

1715636562

[1715636562]

1715636562

[1715636562]

1715636562

[Firebox]

I published a new release. 1.16.

Many thanks, Bro! You are the best!

[bangbumbang]

I will try with 2 GPU to see if something is wrong there...

There is no limitation to find the key of an address, only the time needed

I tried all I can think of here is what I found, maybe that helps:

removing -t 0 and or -o ... and or -b ..   then it runs for exactly 3 sec. with 133 addresses
using different grid size down to 64,128 made it run a few seconds longer .. like 5 sec. or so..
using only gpu 0 then it runs for 30-60 sec. BUT not when using gpu 1... I switched them (pic-e slot) but the same result.. same error..

and still not loading addresses everything works fine...

[bangbumbang]

additionally I was looking at this error when others were having them in there Cuda programs..
GPUEngine: Launch: an illegal memory access was encountered

what they pretty much all had in common was that they referenced an index of an array outside the scope of the array i.e.

Code:

my_array[0..4]=.... 
x = my_array[6] 

or they were referencing the array itself before its existence or instantiation

might this happen here only when the grid size gets "this big" (68x64 cores) Grid(544x128) or more when the core count gets this high, since I did shrink the grid size and it did something but not much???

one more "far out" thing I could think of would be the fact that its an RTX and not a GTX any more, but since Cuda should be backwards compatible it is not something I would really suspect as the cause..

[Jean_Luc]

Search: 21910565 addresses (Lookup size 65536,[259,3090]) [Compressed or Uncompressed]

I never tried 21 million addresses as you, I have to generate such a list and see what will happen.

ps: I only have Cuda 10 installed and gcc is 7.4.0 and as far as I know ccap 75 is the correct platform.. is it not?

VanitySearch.exe -l
(it gives the ccap)

[bangbumbang]

./VanitySearch -gpu -gpuId 0 -i 5000.txt
VanitySearch v1.16
Search: 133 addresses (Lookup size 133,[1,1]) [Compressed]
Start Wed Jan  8 07:56:31 2020
Base Key: CAFFCF119BAE13EAA1F0C053F98BBA2D3982E39B40FB9A991A475F0B46BA4751
Number of CPU thread: 1
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
[2196.82 Mkey/s][GPU 2192.28 Mkey/s][Total 2^37.02][Prob 0.0%][50% in 1.46226e+31y][Found 0]  GPUEngine: Launch: an illegal memory access was encountered

this happens with 133 addresses.. same thing after 3sec. but if it helps I can give you the 22 million file.. its about 750mb.. I was just courious about performance with big datasets so I dumped the p2pkh and the p2pk addresses from the chainstate of a full node and that's about 22mil at the moment...
(if you want to do the same I have a tool on my GitHub that can batch convert the pub keys compressed uncompressed and leveldb encoded to there corresponding addresses because they are only in utxo form in the chainstate.. search for pub2addr)
i haven't looked too hard in your code but r u using a hash table instead of a bloom filter.. right?
and at the moment its just research 4 me but im thinking about implementing a vanity searcher on a Xilinx u200 FPGA... MAYBEEEEEEEEEE.. as a bitstream.. and so im looking around at the moment..

./VanitySearch  -l
GPU #0 GeForce RTX 2080 Ti (68x64 cores) (Cap 7.5) (11016.3 MB) (Multiple host threads)
GPU #1 GeForce RTX 2080 Ti (68x64 cores) (Cap 7.5) (11019.4 MB) (Multiple host threads)

yes it states Cap 7.5 so compiling with ccap=75 seems right..

[Firebox]

I dumped the p2pkh and the p2pk addresses from the chainstate of a full node and that's about 22mil at the moment...

Can you upload this file somewhere and share the link?

[Jean_Luc]

this happens with 133 addresses.. same thing after 3sec. but if it helps I can give you the 22 million file.. its about 750mb.. I was just

Just send me the 133 addresses files via pm. May a particular address inside causes the issue.

[bangbumbang]

Just send me the 133 addresses files via pm. May a particular address inside causes the issue.

done...

thinking about it yeah there are 5 addresses in there that are 1 symbol shorter then full length .. and yeah they would be in the 22mil as well, also even shorter ones! an address can get down to 26 symbols.. I think

here is an additional strange thing.. I ran it against the list without the 5 addresses and instead of failing immediately it ran for 3 min. if I put the -t 0 AND the base key started with 7... on E or C or 2... it failed immediately so I startet several times .. always only when the base key starts with 7 it ran for a moment..

[Jean_Luc]

I ran with your file a bit, even tried to specify your grid size on my old Quadro and it worked.

Code:

pons@linpons:~/VanitySearch$ ./VanitySearch -gpu -gpuId 0,1 -g 544,128,544,128 -i i133.txt 
VanitySearch v1.16
Search: 133 addresses (Lookup size 133,[1,1]) [Compressed]
Start Thu Jan  9 15:38:20 2020
Base Key: 1A85D6F37BBEB28577F03B5329E3A2F0DE5D52A5A2781E266353544121CBA9BB
Number of CPU thread: 1
GPU: GPU #1 Quadro 600 (2x48 cores) Grid(544x128)
GPU: GPU #0 Quadro 600 (2x48 cores) Grid(544x128)

[55.40 Mkey/s][GPU 53.46 Mkey/s][Total 2^31.14][Prob 0.0%][50% in 5.79857e+32y][Found 0]  ^C

Your git is up to date ?

[bangbumbang]

Your git is up to date ?

yeah I made a fresh copy yesterday and compiled it, its 1.16
1.15 had the same problem though

might have the chance to run it on windows next week..
im also trying to find someone that can lend me a gtx for a bit only found a friend with a Vega 64 but this is cuda only no openCL right?

[MrFreeDragon]

Yes it increments the starting priv key at each step but generates also 5 other points from it (no way to disable the 5 extra points without code mods).
To start with a specific priv key, the only way is to specify the corresponding public key using -sp option and reconstruct final key using -rp option.

If specify the corresponding public key using -sp option, the tool just adds some "unknown" number to the priv key. This is very useful for work delegation.

My question was about start search from the exact priv key. You have base key in your tool, but it is not determined as the exact 256bit number to start, it is determined by the seed. How do you receive the base key from the "-s seed" option as the starting point?

[Jean_Luc]

In any case this program is not designed to do that, so this is just tricks and you need to modify the code.
You have to disable the 5 optimized points, to set the startKey to 0 and specify a pub key or add the appropriate option.
You have also to adjust the starting key of each thread in order to cover the desired range.
This is more or less planned but not for the moment.

[cryptoroy]

In any case this program is not designed to do that, so this is just tricks and you need to modify the code.
You have to disable the 5 optimized points, to set the startKey to 0 and specify a pub key or add the appropriate option.
You have also to adjust the starting key of each thread in order to cover the desired range.
This is more or less planned but not for the moment.

Hi, Do you have in plan to add :
-keyspace START:END+Count
-random keyspace between START:END+Count ?

Thx

[Firebox]

Yes it increments the starting priv key at each step but generates also 5 other points from it (no way to disable the 5 extra points without code mods).
To start with a specific priv key, the only way is to specify the corresponding public key using -sp option and reconstruct final key using -rp option.

If specify the corresponding public key using -sp option, the tool just adds some "unknown" number to the priv key. This is very useful for work delegation.

My question was about start search from the exact priv key. You have base key in your tool, but it is not determined as the exact 256bit number to start, it is determined by the seed. How do you receive the base key from the "-s seed" option as the starting point?

Bro, you would probably need VanitySearch-1.15.2_bitcrack for this task.
Run it like:

Code:

VanitySearch-1.15.2_bitcrack -stop -t 0 -gpu -r 10000 -s 0000000000000000000000000000000000000000000000000000000400000000 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb

-s    - start privkey

[Project BULK]

Hello! Is it possible to disable the function (Base Key). The fact is that The Base Key function reduces the search range. Despite the fact that your program is more productive than vanitygen. Vanitygen is able to find matches faster with a short prefix. How can I disable the function of the Base Key? or to configure that your program used constantly random keys for search?

[Jean_Luc]

Hi, Do you have in plan to add :
-keyspace START:END+Count
-random keyspace between START:END+Count ?

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

Hello! Is it possible to disable the function (Base Key). The fact is that The Base Key function reduces the search range. Despite the fact that your program is more productive than vanitygen. Vanitygen is able to find matches faster with a short prefix. How can I disable the function of the Base Key? or to configure that your program used constantly random keys for search?

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.

[Project BULK]

I tested not for 3 characters, but 5 or 6 characters and VanitySearch is very long looking compared to vanitygen

[Project BULK]

I think that the function (Base Key) greatly reduces performance. Because the search range is too narrow. Now, if it as it to disconnect! We can say that this is a useless function, since one character in 160 changes Sha 256 cardinally.

[MrFreeDragon]

I think that the function (Base Key) greatly reduces performance. Because the search range is too narrow. Now, if it as it to disconnect! We can say that this is a useless function, since one character in 160 changes Sha 256 cardinally.

I have the opinion about this, may be not correct. I guess that the base key function is very important for securiyty reasons. Vanitysearch is a tool designed to generate desired vanity addresses. So these addresses also should be secured - for these purposes random base key is used. Without base key fuction 2 different persons could generate the same addresses if use the same prefix - let's say I generate the address starting with "1Dragon", so another person could generate the same address using vanitysearch without base key.

But anyway, if vanitysearch performance without base key is faster, it will be good be able to disable this function (only for advanced users, as it decreases the security).

PS. Without base key, by default users could use number 1 as teh starting private key. So, all different users will generate the same address if use similar prefix, because the tool increment priv key number by 1 searchig for the address.