VanitySearch (Yet another address prefix finder) - page 36.

bangbumbang

jr. member

Activity: 41

Merit: 1

@Jean_Luc

no, 1.15 and 1.16 both do NOT work.. same error when loading lists..

will try with your exe though.. one moment...

what the hell.. im not getting errors on 5 or 6 when using your exe.. could only test for a minute though.. sometimes it took longer to crash

is my compile env gone haywire? I compiled 5 and a few days later 6 with VS19 and only changed the target to my cuda 10.2 env.. was there some change from 10.0?
(ps: no, no compile errors or anything.. just straight forward..)

... will test tonight...

Jean_Luc

sr. member

Activity: 462

Merit: 696

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

bangbumbang

jr. member

Activity: 41

Merit: 1

@Jean_Luc , you are right, 1.14 is working fine... do you have an actual changelog somewhere?

Jean_Luc

sr. member

Activity: 462

Merit: 696

Quote from: loginov on January 24, 2020, 07:48:09 AM

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 think it will work but effectively you may need to install specific CUDA software.

loginov

jr. member

Activity: 36

Merit: 14

Quote from: Jean_Luc on January 24, 2020, 03:46:07 AM

Quote from: loginov on January 23, 2020, 06:19:35 PM

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

Jean_Luc

sr. member

Activity: 462

Merit: 696

Quote from: loginov on January 23, 2020, 06:19:35 PM

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

jr. member

Activity: 36

Merit: 14

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

sr. member

Activity: 462

Merit: 696

Quote from: bad-miner on January 23, 2020, 11:44:52 AM

How do I configure the -g option? Huh

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.

bad-miner

newbie

Activity: 8

Merit: 0

Quote from: Jean_Luc on January 23, 2020, 06:21:32 AM

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? Huh

Tell us more.

bangbumbang

jr. member

Activity: 41

Merit: 1

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?

loginov

jr. member

Activity: 36

Merit: 14

Quote from: Jean_Luc on January 23, 2020, 06:21:32 AM

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!

Jean_Luc

sr. member

Activity: 462

Merit: 696

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

jr. member

Activity: 36

Merit: 14

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?

arulbero

legendary

Activity: 1914

Merit: 2071

Quote from: zielar on January 19, 2020, 09:07:30 AM

Quote from: Jean_Luc on December 27, 2019, 02:33:02 PM

Quote from: zielar on December 27, 2019, 01:39:19 PM

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!

zielar

full member

Activity: 277

Merit: 106

Quote from: Jean_Luc on December 27, 2019, 02:33:02 PM

Quote from: zielar on December 27, 2019, 01:39:19 PM

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

Quote from: Jean_Luc on January 06, 2020, 04:02:10 PM

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

Now works correctly. Thank you!

Quote from: MrFreeDragon on January 12, 2020, 09:24:40 AM

Quote from: Project BULK on January 12, 2020, 08:07:25 AM

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?

Jean_Luc

sr. member

Activity: 462

Merit: 696

Quote from: bangbumbang on January 14, 2020, 07:56:37 AM

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.

Dabs

legendary

Activity: 3416

Merit: 1912

The Concierge of Crypto

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.

bangbumbang

jr. member

Activity: 41

Merit: 1

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]

Project BULK

newbie

Activity: 14

Merit: 0

Thanks!

Jean_Luc

sr. member

Activity: 462

Merit: 696

Quote from: Firebox on January 12, 2020, 11:53:32 AM

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.

Topic: VanitySearch (Yet another address prefix finder) - page 36. (Read 31225 times)