VanitySearch (Yet another address prefix finder)

[Dabs]

I don't think you can get any ASICs meant for mining to work on VanitySearch.

[1715299115]

1715299115

[1715299115]

1715299115

[1715299115]

1715299115

[1715299115]

1715299115

[blockblock1]

I don't think you can get any ASICs meant for mining to work on VanitySearch.

why?
Are there alternative programs?

[OgNasty]

I don't think you can get any ASICs meant for mining to work on VanitySearch.

why?
Are there alternative programs?

None I've ever heard of.  More surprisingly, I'm not even aware of any FPGA vanity searching tools.

[imjustagirl]

It would be nice if you could search for not just a specific Vanity address, but also a specific pubkey address.
For example if I wanted to search for an address with a public key that begins with 0400000000 or 02123456  or 03333333 etc.
Is it very hard to implement something like this to the VanitySearch?

[MrFreeDragon]

It would be nice if you could search for not just a specific Vanity address, but also a specific pubkey address.
For example if I wanted to search for an address with a public key that begins with 0400000000 or 02123456  or 03333333 etc.
Is it very hard to implement something like this to the VanitySearch?

Interesting idea ) Something like vanity public key 
Actually this could be applied to ETH addresses as well (in ETH 256bit public keys are the addresses).

I also suppose that vanity search for BTC public key should be faster (as there is no need to perform RIPEMD 160 and SHA256 hash fuctions)

[A-Bolt]

in ETH 256bit public keys are the addresses

Ethereum address is the lower 20 bytes of the keccack256 hash of the public key.

[MrFreeDragon]

in ETH 256bit public keys are the addresses

Ethereum address is the lower 20 bytes of the keccack256 hash of the public key.

Yeah, right. ETH addresses are 160bit (20x8). I made a mistake. Thank you.

[zielar]

Hello,
I have a question to dispel doubts about the diff index in VanitySearch.
Suppose I am looking for the prefix "1RoseCross".
VanitySearch reports difficulty 173346595075428800 for the indicated prefix.

1. Is this value simply speaking - a group that creates 100% addresses where one of them will start with a given search (1RoseCross)?
2. If YES, is "173346595075428800" a decimal value which in hex is "0x0267d9cf4e7e91c0"?
3. If YES, are there any cases or exceptions in which it will be possible not to find the prefix after scanning the range 173346595075428800 despite the fact that VanitySearch has given such difficulty value?

Thank you in advance for your response!

[Jean_Luc]

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

[arulbero]

Hello,
I have a question to dispel doubts about the diff index in VanitySearch.
Suppose I am looking for the prefix "1RoseCross".
VanitySearch reports difficulty 173346595075428800 for the indicated prefix.

1. Is this value simply speaking - a group that creates 100% addresses where one of them will start with a given search (1RoseCross)?

The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

To be more precise:

difficulty = 173346595075428800 means that:
--> there is a correct address each 173346595075428800  addresses
--> you have a probability of 1/173346595075428800 to find the result each 1 try
--> on average it takes 173346595075428800 tries to get 1 match (on average means: if you try many times 173346595075428800 tries), but if you do 173346595075428800 tries only once you will have only a 63% chance to get a match! No 100%!

Any vanitygen-like program computes right the probability to find a match in the particular sequence you are running, it doesn't compute anything "on average".

Search space size is not 173346595075428800, sometimes you have to generate more than 173346595075428800 addresses to get a match.
A group that creates 100% addresses where one of them will start with a given prefix has size 2^160 - 173346595075428800 + 1 (and I'm not considering the fact that there are 2^96 different private keys - means tries - for the same address).

Here more details:
https://bitcointalk.org/index.php?topic=5068417.msg48056010#msg48056010

[arulbero]

@Jean-Luc

Could you implement the possibility to import a different generator point G as parameter?

To run your program on unsafe machine:

https://bitcointalk.org/index.php?topic=5211545.msg53429180#msg53429180

[zielar]

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

I am asking because I have scanned the range of keys being the number given by Diff, but I have not found a solution.

1. What is the remainder of the range that I should scan to find the answer?
2. The fact that I did not find the correct key despite this is not the reason for the error in the code?

[arulbero]

Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n

I am asking because I have scanned the range of keys being the number given by Diff, but I have not found a solution.

1. What is the remainder of the range that I should scan to find the answer?
2. The fact that I did not find the correct key despite this is not the reason for the error in the code?

I already answered to you: difficulty is not the range you should scan to find the solution at 100% : you have in the above example  

P(173346595075428800) =  1-(1-1/173346595075428800)^173346595075428800 = 0.63 --> 63% ( = 1-1/e),  not 100%!

That means that only 2 times each 3 you will find the solution in a range = difficulty.

[Jean_Luc]

@Jean-Luc

Could you implement the possibility to import a different generator point G as parameter?

To run your program on unsafe machine:

https://bitcointalk.org/index.php?topic=5211545.msg53429180#msg53429180

Yes why not.
I plan to change the implementation of the -sp option. Rather using a mod ModAdd for the final priv key reconstruction, it would be simpler as you suggest to use ModMul and this method should be independent of symmetry or endomorphism optimizations. It will also simplify the implementation but I don't know if VanityPool supports ModMul for reconstruction. I think it does, but I'm not sure.

[arulbero]

Yes why not.
I plan to change the implementation of the -sp option. Rather using a mod ModAdd for the final priv key reconstruction, it would be simpler as you suggest to use ModMul and this method should be independent of symmetry or endomorphism optimizations. It will also simplify the implementation but I don't know if VanityPool supports ModMul for reconstruction. I think it does, but I'm not sure.

I think it doesn't, but the goal is different: generate a vanity address on unsafe machine or delegate this work to others in a trustless way (indipendently from what VanityPool does).

[judypug1956]

What is a good cpu and or gpu to use for this?

 I have a ryzen 9 3900 each one does 24 threads.

I have a long vanity in mind 1234567890     ten long

1 pc has 50-50 shot after 320 days

I am trying to do this with a cpu vs a gpu

but I am willing to use a gpu is it is better.

[judypug1956]

Has anyone put together (or started to put together) a list of CPUs / Video Cards & the speed you can get out of them.
I know it's a newer project and Jean_Luc is working VERY VERY hard on it so getting accurate numbers is going to be a moving target. But for now all we can do is look through the thread and see who is running what to get a general idea.
So far I have pulled from this thread:

GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128)
914.418 MK/s (GPU 896.216 MK/s)

GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
220.180 MK/s (GPU 220.180 MK/s)

GPU: GPU #0 GeForce GT 520M (1x48 cores) Grid(8x128)
10.233 MK/s (GPU 7.026 MK/s)

GPU: GPU #0 GeForce RTX 2070 (36x64 cores) Grid(288x128)
1535.880 MK/s (GPU 1470.257 MK/s)

Added 30-April-2019

GPU: GPU #0 GeForce GTX 1060 3GB (9x128 cores) Grid(72x128)
321.929 MK/s (GPU 321.929 MK/s)

GPU: GPU #0 GeForce GTX 1080 (20x128 cores) Grid(160x128)
672.062 MK/s (GPU 672.062 MK/s)

Added 1-May-2019

GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #3 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #2 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #1 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
7260.449 MK/s (GPU 7212.931 MK/s)
So 7260 / 4 = 1815 MK/s

GPU: GPU #0 GeForce GTX 750 (4x128 cores) Grid(32x128)
104.960 MK/s (GPU 94.405 MK/s) (2^32.12)

Added 3-May-2019
i7-7700K CPU Number of CPU thread: 8
22.092 MK/s (GPU 0.000 MK/s)

With -t 7
Number of CPU thread: 7
21.609 MK/s

Added 8-May-2019

EVGA RTX 2080 XC ULTRA
1427.967 MK/s (GPU 1424.946 MK/s)

Added 23-May-2019

GPU: GPU #0 GeForce GTX 1660 Ti
961.319 MK/s (GPU 961.319 MK/s)

GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
5128.213 MK/s (GPU 5128.213 MK/s)
So 5128 / 2  = 2564 MK/s


Added 8-June-2019

GPU: GPU #0 GeForce GTX 960M (5x128 cores) Grid(40x128)
117.802 MK/s (GPU 117.802 MK/s)

Added 23-July-2019

GPU: GPU #0 GeForce GTX 1660 (22x64 cores) Grid(176x128)
839.061 MK/s (GPU 839.061 MK/s)

Added 25-July-2019

GPU: GPU #0 GeForce GTX 1650 (14x64 cores) Grid(112x128)
511.906 MK/s (GPU 511.906 MK/s) (2^36.97)


Added 21-Nov-2019

GPU: GPU #0 GeForce GTX 970 (13x128 cores) Grid(104x128)
360.322 MK/s (GPU 331.442 MK/s) (2^32.77)

Added 25-Nov-2019

GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
375.384 MK/s (GPU 375.384 MK/s)

GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[1361.71 Mkey/s][GPU 1361.71 Mkey/s]

GPU: GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256)
[2001.52 Mkey/s][GPU 2001.52 Mkey/s]

Anything else?

-Dave

Last updated 25-Nov-2019.

Right now I am using

 a ryzen 9 3900 but I am using vanitygen64  it does a mere 4.7  with 24threads
vs 8 threads of an intel i7 7700k and vanitysearch doing 22.092mk

so it looks like this is better then vanitygen

[Jean_Luc]

I think it doesn't, but the goal is different: generate a vanity address on unsafe machine or delegate this work to others in a trustless way (indipendently from what VanityPool does).

There is already a split-key mechanism that allows this, do you have issue with it ?

[arulbero]

I think it doesn't, but the goal is different: generate a vanity address on unsafe machine or delegate this work to others in a trustless way (indipendently from what VanityPool does).

There is already a split-key mechanism that allows this, do you have issue with it ?

It allows this but you have to accept a lower speed: if your goal is to generate as fast as possible a vanity address on unsafe machine (or to pay less a third part exploiting completely its hardware) the spli-key mechanism is not the best option.

[Jean_Luc]

When using splitkey, there is just a add of the specified public key at the beginning of the search. It should not  bring a significant overload.
I will make further tests.
Changing G is easy to do for CPU code, but more difficult in GPU code. The generator table is stored in constant memory and precalculated in a header file (GPU/GPUGroup.h), this has to be redone...