VanitySearch (Yet another address prefix finder)

[Project BULK]

The base key is a security risk because it narrows the search range. I would like to search for matches across the entire range of keys. This will be true randomization.

[1715451686]

1715451686

[1715451686]

1715451686

[1715451686]

1715451686

[1715451686]

1715451686

[1715451686]

1715451686

[Project BULK]

Good! Is there a security audit of this program? I personally can't read the code, and neither can 99 percent of users. And what if the developer of this program has implemented in the code that the basic keys are repeated. It may be a large range, so users will not notice. Then, at the appropriate time, all addresses created with this program will be emptied. So the base key is a security threat.

[Firebox]

Good! Is there a security audit of this program? I personally can't read the code, and neither can 99 percent of users. And what if the developer of this program has implemented in the code that the basic keys are repeated. It may be a large range, so users will not notice. Then, at the appropriate time, all addresses created with this program will be emptied. So the base key is a security threat.

You must be crazy, man, to store your bitcoins on the vanity addresses generated by the tool the source code of which you are not able to read and understand.

[Project BULK]

Can't you read? It describes the essence of the problem. And pick up expressions when writing to strangers.

[Jean_Luc]

You must be crazy, man, to store your bitcoins on the vanity addresses generated by the tool the source code of which you are not able to read and understand.

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.

[Project BULK]

Thanks!

[bangbumbang]

Hey
@Jean_Luc

I tried under windows 10..

seems to be the same.. everything works except loading lists..
the error message is a little different though if I use -b or not..

-b:

Code:

Vanitysearch.exe -t 5 -b -gpu -gpuId 0,1 -o found.txt -i 5000_2.txt
VanitySearch v1.16
Search: 128 addresses (Lookup size 128,[1,1]) [Compressed or Uncompressed]
Start Mon Jan 13 15:50:02 2020
Base Key: 52C72D03D79BBE9E353E4F94C4DA98D670319CAFDE77BA6CED88F869A46B78D4
Number of CPU thread: 5
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPUEngine: SetKeys: an illegal memory access was encountered
GPUEngine: Kernel: an illegal memory access was encountered
GPUEngine: Launch: an illegal memory access was encountered

without -b:

Code:

Vanitysearch.exe -gpu -gpuId 0,1 -o found.txt -i 5000_2.txt
VanitySearch v1.16
Search: 128 addresses (Lookup size 128,[1,1]) [Compressed]
Start Mon Jan 13 15:52:57 2020
Base Key: A710A6BA12BEFC65131BCDE3EFFE9516BE675645578DF60624F69E8A67817605
Number of CPU thread: 10
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPUEngine: Launch: an illegal memory access was encountered
GPUEngine: Launch: an illegal memory access was encountered/code]

[Dabs]

There are so many "base" keys the dev can't store them all or precalculate them - such as with a master or root key - without being seen or noticed in the code.

[Jean_Luc]

Hey
@Jean_Luc

I tried under windows 10..

seems to be the same.. everything works except loading lists..
the error message is a little different though if I use -b or not..

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

[zielar]

This is not exactly the answer to my question - "Is there a number that creates a range that makes up 100% of the pool in which the prefix is located?"

However, thanks for the calculation and explanation.
What the case looks like in case of difficulties 10054102514374868992
What percentage does this number specify? (I can't find an effective calculation method myself)

I'm not sure to fully understand the question.
If I understand well, there is no way to define a group with a specific size where you are 100% sure that a given prefix is located because addresses are randomly distributed. As said in above posts, the difficulty give the probability to hit a particular prefix after 1 try, nothing more...
63% means that if you make 173346595075428800 tries, you will have 63% of chance to find the desired prefix.

So explaining in the simplest understandable way:
115792089237316195423570985008687907852837564279074904382605163141518161494336 - the size of the entire BTC range
173346595075428800 means as if every "173346595075428800" of spaces appears the prefix searched, but they are not evenly distributed across the full range (i.e. that I can search 10x the whole "173346595075428800" without finding the solution, and searching the 11th range I will find solutions eleven)?
I have scanned the continuous range of over 505000000000000000 (decimal) in order to find a solution for a vanity address with the aforementioned difficulty value with no results and this probably allowed me to understand the above ...

I just updated CUDA8 project files for VS2015.
Let me know if it is better...

Now works correctly. Thank you!

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.

I have a different opinion on this topic:
1. The option of manually setting BaseKey will not affect your security in any way, because manual setting has exactly the same number of combinations - how many random combinations can the machine generate.
2. The implementation of the option of manual determination (with security) should work so that by default the application generates a random key (as it does by default), while for advanced users - it gives the ability to disable the generation of BaseKey (with forced own input)
3. The above points are justified, because no one who turns off the random BaseKey mode (differently each time) consciously - will not do it to find an empty address for the purpose of storing funds for which BaseKey was used 0x00000000000000000000000000000000000000000000000000000000000000001


Now wanting to dispel doubts:
1. Do they have any impact on the functioning of VanitySearch:
- pagefile size and virtual memory settings:

- "lock pages in memory" settings from gpedit.msc:

- setting the manual value -m in VanitySearch
2. What values should I use by default to get the best working environment for VanitySearch in Windows for the ONE vanity address I am looking for?

[arulbero]

This is not exactly the answer to my question - "Is there a number that creates a range that makes up 100% of the pool in which the prefix is located?"

However, thanks for the calculation and explanation.
What the case looks like in case of difficulties 10054102514374868992
What percentage does this number specify? (I can't find an effective calculation method myself)

I'm not sure to fully understand the question.
If I understand well, there is no way to define a group with a specific size where you are 100% sure that a given prefix is located because addresses are randomly distributed. As said in above posts, the difficulty give the probability to hit a particular prefix after 1 try, nothing more...
63% means that if you make 173346595075428800 tries, you will have 63% of chance to find the desired prefix.

So explaining in the simplest understandable way:
115792089237316195423570985008687907852837564279074904382605163141518161494336 - the size of the entire BTC range
173346595075428800 means as if every "173346595075428800" of spaces appears the prefix searched, but they are not evenly distributed across the full range (i.e. that I can search 10x the whole "173346595075428800" without finding the solution, and searching the 11th range I will find solutions eleven)?

Yes!

[loginov]

What are the best options to use for maximum Mkeys/s output?

I assume that -u (search uncompressed addresses) is quicker than -b (search compressed and uncompressed addresses).

For -i (the input file) - I'm unclear about what's in that file. Is it just a list of prefixes you want e.g:
1abc
1def
1ghi
...

Or something else? I see people using input files with hundreds of lines but they don't post the content of those input files.

Can someone give an example, please?

[Jean_Luc]

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:

Code:

1Pierre
1PauL
1Jacques

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

[loginov]

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:

Code:

1Pierre
1PauL
1Jacques

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

Thanks - I'm trying this now.

That seems much quicker!

[bangbumbang]

Hey
@Jean_Luc

I tried my own (new) 2080 Ti.. the same...


@all:

is there anyone with a 2080 Ti or two where this is working with address lists?

[bad-miner]

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:

Code:

1Pierre
1PauL
1Jacques

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

How do I configure the -g option? Tell us more.

[Jean_Luc]

How do I configure the -g option? Tell us more.

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.

[loginov]

In terms of GPU:

My impression is that 18.04 is required for Vanity Search. Is there a particular model of NVIDIA / CUDA that you (or anyone) would recommend?

From the NVIDIA site the options for Ubuntu 18.04 are:

    10.2-base, 10.2-base-ubuntu18.04 (10.2/base/Dockerfile)

    10.2-runtime, 10.2-runtime-ubuntu18.04 (10.2/runtime/Dockerfile)

    10.2-cudnn7-runtime, 10.2-cudnn7-runtime-ubuntu18.04 (10.2/runtime/cudnn7/Dockerfile)
    latest,

    10.2-devel, 10.2-devel-ubuntu18.04 (10.2/devel/Dockerfile)

    10.2-cudnn7-devel, 10.2-cudnn7-devel-ubuntu18.04 (10.2/devel/cudnn7/Dockerfile)

Thanks - again!

[Jean_Luc]

My impression is that 18.04 is required for Vanity Search.

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....

[loginov]

My impression is that 18.04 is required for Vanity Search.

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....

So do you think that the standard 18.04 distro will work for GPU? Or would I need to install some specific CUDA software for 18.04?

I know it works for CPU (as long as you install g++).