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

Jean_Luc

sr. member

Activity: 462

Merit: 701

The memory needed to transfer results from GPU to CPU depends on the number of prefixes your search for, the number of threads and the rareness of the prefix(es).
The maximum number of hits per kernel call is maxFound = gridSize*1024*6
If you have enough memory available, you can specify -m gridSize*1024*6 to avoid the error.

Note: The corresponding amount of shared memory needed is 28*maxFound + 4 bytes.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Code:

Warning, XXX items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)

Can somebody explain how to change -m value in order not to lose items?
Is it means that XXX items were not included into the search, and the search is made for the remaining prefixes?

cryptoroy

newbie

Activity: 4

Merit: 0

Quote from: Telariust on August 08, 2019, 08:17:56 PM

Quote from: Jean_Luc on June 16, 2019, 12:50:37 AM

.. reduce it to only one is not obvious.

This is exactly what was required to be done!

I just commented out all the symY/endo; also excluded the use of the algo for compressed keys with negative zero.
You can to add a separate release how did you do it for cuda8 and sm30.
(by the way, why does release sm30 load sm60 cores, is there no error here?)

You need? You do! Grin

(sry my obsession)

[VanitySearch v1.15 origin]

Code:

>VanitySearch-1.15 -nosse -stop -t 4 12345678
5.275 MK/s (GPU 0.000 MK/s) (2^25.92) [P 0.01%][50.00% in 1.4d][0]

>VanitySearch-1.15 -stop -t 4 12345678
11.221 MK/s (GPU 0.000 MK/s) (2^28.44) [P 0.04%][50.00% in 15:14:11][0]

>VanitySearch-1.15 -gpu -stop -t 0 12345678
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
375.384 MK/s (GPU 375.384 MK/s) (2^32.96) [P 0.94%][50.00% in 00:26:58][0]

[VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)]

Code:

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -nosse -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd 12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug 8 12:11:09 2019
Base Key: 6B10396F80C062F2474865C76739A1D1C815F9B9EECFA46B328F90118FD0149E
Number of CPU thread: 4
4.464 MK/s (GPU 0.000 MK/s) (2^28.80) [P 100.00%][99.00% in 00:00:00][101]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd 12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug 8 12:13:13 2019
Base Key: D56EE34383C48B0D4194E834A7955021879BF3AB5444019168768D58BE4E3895
Number of CPU thread: 4
8.212 MK/s (GPU 0.000 MK/s) (2^28.63) [P 100.00%][99.00% in 00:00:00][105]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235 12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Uncompressed, with public key]
Start Thu Aug 8 12:14:52 2019
Base Key: 3B08999D16D9E5AF4EE27B7F5D8748B63D62446FB54B2BD1B7A28E46FCF30570
Number of CPU thread: 4
5.963 MK/s (GPU 0.000 MK/s) (2^28.82) [P 100.00%][99.00% in 00:00:00][107]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd 123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Compressed, with public key]
Start Thu Aug 8 12:16:56 2019
Base Key: ED70397FC554858B8F3D3A84C5B4A1B50E5B289315F4833BDFEA93806740B572
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
197.134 MK/s (GPU 197.134 MK/s) (2^34.37) [P 100.00%][99.00% in 00:00:00][100]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235 123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Uncompressed, with public key]
Start Thu Aug 8 12:19:26 2019
Base Key: 74317CCE4CC9525C7A6F276A82E13C7E325DA6B6DD04F673759D8497B524D6D0
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
158.337 MK/s (GPU 158.337 MK/s) (2^34.64) [P 100.00%][99.00% in 00:00:00][100]

..with regard to..

Quote from: Jean_Luc on March 04, 2019, 10:06:09 AM

Code:

[quote author=stivensons link=topic=5112311.msg50017516#msg50017516 date=1551710888]
Will there be settings like Bitcrack in the future?
-i, --in FILE
Read addresses from FILE, one address per line. If FILE is "-" then stdin is read

Yes, I'm thinking to add this. It will need an important refurbishment of the code however it goes in the same way as optimizing data transfer. So probably yes.

Quote from: stivensons on March 04, 2019, 09:48:08 AM

Code:

--keyspace KEYSPACE
Specify the range of keys to search, where KEYSPACE is in the format,

START:END start at key START, end at key END
START:+COUNT start at key START and end at key START + COUNT
:END start at key 1 and end at key END
:+COUNT start at key 1 and end at key 1 + COUNT

No (if I understand well the purpose of this option).
VanitySearch is a prefix finder in order to generate usable addresses, you can specifie a seed to generate a base key ,it is even recommended. That's all. The seed is then passed into a pbkdf2_hmac_sha512 in order to protect against seed search attack. If you don't specifie the seed, the basekey is generated using timestamps (in us) plus the date and also passed into the pbkdf2_hmac_sha512.
The result of the pbkdf2_hmac_sha512 is then passed into a SHA256 wich is use as the base key.

[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]

RANGE: 0xF00000000 - 0xA00000000 = 0x500000000 (21,474,836,480)

Code:

>powershell Get-Date && VanitySearch-1.15_bitcrack -stop -t 0 -gpu -r 10000 -s 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg && powershell Get-Date

8 Aug 2019 y. 22:54:43

VanitySearch v1.15.2, add BitCrack mode, startPrivKey from seed arg
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg [Compressed]
Start Thu Aug 8 22:54:44 2019
Starting at PrivKey: 0x0000000000000000000000000000000000000000000000000000000A00000000
Save progress every 10000 Mkeys
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)

[save] 0x0000000000000000000000000000000000000000000000000000000A00000000
197.135 MK/s (GPU 197.135 MK/s) (2^33.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000C540BE400
197.135 MK/s (GPU 197.135 MK/s) (2^34.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000EA817C800
196.087 MK/s (GPU 196.087 MK/s) (2^34.48) [P 0.00%][50.00% in 1.63821e+32y][0]

Pub Addr: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9MxjBfWawjmiQu7
Priv (HEX): 0x0000000000000000000000000000000000000000000000000000000F00000000

8 Aug 2019 y. 22:56:48

RUNTIME: 22:56:48 - 22:54:43 = 00:02:05 (125sec)

[BitCrack v0.30]

Code:

>powershell Get-Date && cuBitCrack-0.30 -c -d 0 -b 32 -t 512 -p 64 --keyspace 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg && powershell Get-Date

8 Aug 2019 y. 23:06:32

[2019-08-08.23:06:33] [Info] Compression: compressed
[2019-08-08.23:06:33] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000A00000000
[2019-08-08.23:06:33] [Info] Ending at: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
[2019-08-08.23:06:33] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-08-08.23:06:33] [Info] Initializing GeForce GTX 980
[2019-08-08.23:06:33] [Info] Generating 1,048,576 starting points (40.0MB)
[2019-08-08.23:06:33] [Info] 10.0%
[2019-08-08.23:06:33] [Info] 20.0%
[2019-08-08.23:06:33] [Info] 30.0%
[2019-08-08.23:06:33] [Info] 40.0%
[2019-08-08.23:06:33] [Info] 50.0%
[2019-08-08.23:06:34] [Info] 60.0%
[2019-08-08.23:06:34] [Info] 70.0%
[2019-08-08.23:06:34] [Info] 80.0%
[2019-08-08.23:06:34] [Info] 90.0%
[2019-08-08.23:06:34] [Info] 100.0%
[2019-08-08.23:06:34] [Info] Done
GeForce GTX 980 490 / 8192MB | 1 target 107.17 MKey/s (21,418,213,376 total) [00:03:11][2019-08-08.23:09:48] [Info] Address: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
   Private key: 0000000000000000000000000000000000000000000000000000000F00000000
   Compressed: yes
   Public key:
   0382113A9377D0B8638231D9669811A7022B31F5805B0AE2C4E0C0A6B7C3C934B3

[2019-08-08.23:09:48] [Info] No targets remaining

8 Aug 2019 y. 23:09:48

RUNTIME: 23:09:48 - 23:06:32 = 00:03:16 (196sec)

COMPARE
if runtime right:
196s / 125s = ~1,56
if hashrate right:
195MK/s / 105Mk/s = ~1,85

VanitySearch win! Cool

(issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..)

source and binary attached
i warn, only 1 gpu is supported!
i warn, on modern gpu (gtx1070) will get equal or decrease in speed (engine need some fix without 5algo)!
just to make sure that the numbers are real - the symmetrical inversion of the pack is really faster.
https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip

##########################
updated

Need retest gtx980 for cuBitCrack (bad arg -p 64, -p 1024 more optimal, iam sry)

Code:

>VanitySearch-1.15 -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
381.087 MK/s (GPU 381.087 MK/s) (2^32.31) [P 0.01%][50.00% in 1.1d][0]

>VanitySearch-1.15.2_bitcrack -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
199.652 MK/s (GPU 199.652 MK/s) (2^30.89) [P 0.00%][50.00% in 1.60896e+32y][0]

>cuBitCrack-0.30 -c -d 0 -b 16 -t 512 -p 1024 ...
GeForce GTX 980 1240 / 8192MB | 1 target 157.66 MKey/s (1,996,488,704 total)

and now
gtx980 hashrate VSBC/BC = 199/157 = x1.25

GREAT JOB WITH VanitySearch-1.15.2_bitcrack.
Will be great if you can add to VanitySearch-1.15.2_bitcrack_prototype

-rr random key search after -r xcount!

WhyFhy

hero member

Activity: 1438

Merit: 513

Quote from: arulbero on December 26, 2019, 03:38:33 PM

Quote from: Jean_Luc on December 26, 2019, 03:27:13 PM

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

Tesla V100 I have a couple for sell. They are pricey , the rtx 2080 seems like a good contender too. I got about 1.8 billion kps on v100

Jean_Luc

sr. member

Activity: 462

Merit: 701

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.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: Dabs on December 06, 2019, 09:42:34 AM

-snip-
...they just start at some random number in the space and then increment by 1 each time until it finds a match.
-snip-

Jean_Luc, can you confirm that your software increment private key by 1 each step? There is a base key also as an input variable - can you also help how to determine the basic starting point as a private key number, but not some hash from the starting base seed. For example, I want to start search from the certain number (2^255 + 2^173) - is it possible it in your soft?

arulbero

legendary

Activity: 1932

Merit: 2077

Quote from: zielar on December 27, 2019, 12: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?"

The answer was here:

Quote from: arulbero on December 26, 2019, 06:18:37 AM

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

in other terms: no, there is not such a number, or if you prefer there is but it is a very very large number, something like

2^256 - (2^160/difficulty)*2^96

where (2^160 / difficulty) is the size target (number of addresses with a given prefix, 2^96 is the average number of private keys to the same address).

But nobody knows exactly how many private keys generate addresses with a given prefix, it is only a estimate!

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

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)

difficulty = 10054102514374868992 = 2^(63.1)
number of keys we have to use (= number of addresses we have to generate to get on average 1 match)

target = 2^160 / 10054102514374868992 = 1.453637095147298e+29 = 2^(96.9)
number of addresses in target

difficulty * target = 2^160 (all addresses)!

The difficulty is how much the set of all addresses is bigger than set of the target addresses. In this case:

difficulty = set of all addresses / target set = 2^160 / 2^(96.9) = 2^(63.1)

Smaller is the target, bigger is the difficulty to hitting it and viceversa.

How to compute the probability?

The formula (probability to hit a element in the target set in n tries) is:

P(n) = 1-(1-p)^n

where p = 1/difficulty (probability to get a match each try).

In your case:
p = 9.946 * 10^(-20)

P(1) = 1-(1-p)^1 = p = 9.946 * 10^(-20)
P(100) = 1-(1-p)^100 = 9.94 * 10^(-18)
P(10054102514374868992) = 1-(1-p)^10054102514374868992 = 0.63 -> 63%
P(2*10054102514374868992) = 1-(1-p)^2*10054102514374868992 = 0.86 -> 86%
P(3*10054102514374868992) = 1-(1-p)^3*10054102514374868992 = 0.95 -> 95%

P(k*diff) = 1-(1-p)^k*diff = 1- e^-k (this way is more simple to compute)

If you want to know what is n to get P(n)=99%

--> 1-(1-p)^k*diff = 1 - e^-k = 0.99
--> e^-k = 0.01
--> k = -ln(0.01) = 4.6 --> n = 4.6 * 10054102514374868992

P(4.6*10054102514374868992) = 1-(1-p)^4.6*10054102514374868992 = 0.99 -> 99%

P(6.9*10054102514374868992) = 1-(1-p)^6.9*10054102514374868992 = 0.999 -> 99.9%

and so on.

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: zielar on December 27, 2019, 12: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.

zielar

full member

Activity: 282

Merit: 114

Quote from: arulbero on December 26, 2019, 11:33:04 AM

Quote from: zielar on December 26, 2019, 09:42:38 AM

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

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.

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)

arulbero

legendary

Activity: 1932

Merit: 2077

Quote from: Jean_Luc on December 27, 2019, 03:00:31 AM

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.

I thought it were slower (I didn't try, I read it somewhere in the thread). In this case there is no difference.

Jean_Luc

sr. member

Activity: 462

Merit: 701

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

arulbero

legendary

Activity: 1932

Merit: 2077

Quote from: Jean_Luc on December 27, 2019, 02:12:05 AM

Quote from: arulbero on December 26, 2019, 03:38:33 PM

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

sr. member

Activity: 462

Merit: 701

Quote from: arulbero on December 26, 2019, 03:38:33 PM

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 ?

judypug1956

sr. member

Activity: 355

Merit: 276

Quote from: DaveF on April 29, 2019, 09:27:50 AM

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

judypug1956

sr. member

Activity: 355

Merit: 276

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.

arulbero

legendary

Activity: 1932

Merit: 2077

Quote from: Jean_Luc on December 26, 2019, 03:27:13 PM

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

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: arulbero on December 26, 2019, 06:35:38 AM

@Jean-Luc

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

To run your program on unsafe machine:

https://bitcointalksearch.org/topic/m.53429180

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

legendary

Activity: 1932

Merit: 2077

Quote from: zielar on December 26, 2019, 09:42:38 AM

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

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.

zielar

full member

Activity: 282

Merit: 114

Quote from: Jean_Luc on December 26, 2019, 05:09:52 AM

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

legendary

Activity: 1932

Merit: 2077

@Jean-Luc

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

To run your program on unsafe machine:

https://bitcointalksearch.org/topic/m.53429180

Topic: VanitySearch (Yet another address prefix finder) - page 39. (Read 32072 times)