VanitySearch (Yet another address prefix finder)

[arulbero]

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.

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

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)

[Jean_Luc]

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.

[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?"

The answer was here:

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!

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.

[MrFreeDragon]

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

[Jean_Luc]

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.

[WhyFhy]

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

[cryptoroy]

..new 5 ecc algorithms uncompatible with split-key project vanitypool.appspot.com

To make it compatible with the pool, you need to add a splitkey after applying symY/endomorph right before hash160.
It’s not very difficult there, but the performance will suffer, because the operations of adding points are added.
..
I have fixed a few functions for cpu -nosse only, a rough prototype demonstrating that this is possible.
Code is sloow, and problem not in sse. I think secp->AddDirect() is really tardy. I hope you find a quick solution.

..AddDirect requires a modular inversion which costs hundreds of modular multiplications.  goup/sym/endo optimization is done to avoid slow modular inversions..

Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..

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

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.

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!  
(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!

[MrFreeDragon]

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?

[Jean_Luc]

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.

[zielar]

I see that you have resumed the project. I enjoy it!
In this connection, I would like to know:
1. Are you planning to implement instructions supported by the latest processors? (SSE5, AVX512 etc.)?
2. Will you implement a function that allows you to manually adjust the search scope? (the function is necessary for addresses with a higher degree of difficulty [e.g. 10054102514374868992] where randomness each time the scan is started reduces the potential chance of finding the address faster.
3. I have to compile and test a laptop with GPU on SM_20 architecture [for code testing is enough], but I have a problem with compilation. The highest driver for my [GeForce 410M] card is 391.35, so CUDA 9.2. Compiling on CUDA8 crashes me an error, and CUDA 10 causes an invalid driver error on startup. How do I run VanitySearch without an error on SM_20?
4. What modifications are currently under development and will you publish?

Regards

[edit]
You have a typing error in the file  GPU/GPUEngine.h (line 59)

Code:

GPUEngine(int nbThreadGroup,int nbThreadPerGourp,int gpuId,uint32_t maxFound,bool rekey); 

[Jean_Luc]

1. Are you planning to implement instructions supported by the latest processors? (SSE5, AVX512 etc.)?

I do not have such a processor, just an old core i7-4770. May be few optimizations with AVX2...

2. Will you implement a function that allows you to manually adjust the search scope? (the function is necessary for addresses with a higher degree of difficulty [e.g. 10054102514374868992] where randomness each time the scan is started reduces the potential chance of finding the address faster.

I do not really understand the purpose here. Searching in a specific range (for private keys) does not improve chance of finding a match and you also loose the sym/endo optimizations.

3. I have to compile and test a laptop with GPU on SM_20 architecture [for code testing is enough], but I have a problem with compilation. The highest driver for my [GeForce 410M] card is 391.35, so CUDA 9.2. Compiling on CUDA8 crashes me an error, and CUDA 10 causes an invalid driver error on startup. How do I run VanitySearch without an error on SM_20?

I will try on my linux machine with SM_20 and on an other windows pc set up with cuda 8.

4. What modifications are currently under development and will you publish?

For the moment, the main mods is the possibilitty to set up freely the gridSize (x,y)

You have a typing error in the file  GPU/GPUEngine.h (line 59)

Thanks corrected.

[zielar]

Unfortunately, i cannot confirm that on Windows 10 and VS 2015....
This is dump from compilation log:

Code:

1>------ Build started: Project: VanitySearchCUDA8, Configuration: Release x64 ------
1>  Compiling CUDA source file GPU\GPUEngine.cu...
1>
1>  C:\Users\VAIO\Downloads\appspot\full>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64"  -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include"     --keep-dir x64\Release -maxrregcount=0 --ptxas-options=-v --machine 64 --compile -cudart static     -D_CRT_SECURE_NO_WARNINGS -DWITHGPU -DWIN32 -DWIN64 -DNDEBUG -D_CONSOLE -D_MBCS -Xcompiler "/EHsc /W3 /nologo /O2 /FS /Zi  /MT " -o x64\Release\GPUEngine.cu.obj "C:\Users\VAIO\Downloads\appspot\full\GPU\GPUEngine.cu"
1>  ptxas info    : 59 bytes gmem, 33456 bytes cmem[2], 8 bytes cmem[14]
1>  ptxas info    : Compiling entry function '_Z14comp_keys_p2shjPtPjPyjS0_' for 'sm_20'
1>  ptxas info    : Function properties for _Z14comp_keys_p2shjPtPjPyjS0_
1>      16752 bytes stack frame, 436 bytes spill stores, 868 bytes spill loads
1>  ptxas info    : Used 63 registers, 80 bytes cmem[0], 28 bytes cmem[16]
1>  ptxas info    : Function properties for _Z10CheckPointPjiiiPtS_jS_i
1>      72 bytes stack frame, 20 bytes spill stores, 20 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetAddressiPjPc
1>      160 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetHash160PyS_Ph
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z13CheckP2SHHashjPtPyS0_iPjjS1_
1>      48 bytes stack frame, 44 bytes spill stores, 44 bytes spill loads
1>  ptxas info    : Function properties for _Z14_ModInvGroupedPA4_y
1>      16592 bytes stack frame, 308 bytes spill stores, 276 bytes spill loads
1>  ptxas info    : Function properties for _Z15_GetHash160CompPyhPh
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z17CheckHashP2SHCompPtPyhiPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z19CheckHashP2SHUncompPtPyS0_iPjjS1_
1>      48 bytes stack frame, 28 bytes spill stores, 28 bytes spill loads
1>  ptxas info    : Function properties for _Z19_GetHash160P2SHCompPyhPh
1>      24 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z21_GetHash160P2SHUncompPyS_Ph
1>      24 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z6_MatchPKcS0_
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z7_ModInvPy
1>      96 bytes stack frame, 200 bytes spill stores, 204 bytes spill loads
1>  ptxas info    : Compiling entry function '_Z17comp_keys_patternjPtPyjPj' for 'sm_20'
1>  ptxas info    : Function properties for _Z17comp_keys_patternjPtPyjPj
1>      16752 bytes stack frame, 428 bytes spill stores, 852 bytes spill loads
1>  ptxas info    : Used 63 registers, 72 bytes cmem[0], 28 bytes cmem[16]
1>  ptxas info    : Function properties for _Z10CheckPointPjiiiPtS_jS_i
1>      72 bytes stack frame, 24 bytes spill stores, 28 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetAddressiPjPc
1>      160 bytes stack frame, 4 bytes spill stores, 4 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetHash160PyS_Ph
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z13CheckHashCompPtPyhiPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z14_ModInvGroupedPA4_y
1>      16592 bytes stack frame, 308 bytes spill stores, 276 bytes spill loads
1>  ptxas info    : Function properties for _Z15CheckHashUncompPtPyS0_iPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z15_GetHash160CompPyhPh
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z6_MatchPKcS0_
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z7_ModInvPy
1>      96 bytes stack frame, 200 bytes spill stores, 204 bytes spill loads
1>  ptxas info    : Function properties for _Z9CheckHashjPtPyS0_iPjjS1_
1>      48 bytes stack frame, 44 bytes spill stores, 56 bytes spill loads
1>  ptxas info    : Compiling entry function '_Z14comp_keys_compPtPjPyjS0_' for 'sm_20'
1>  ptxas info    : Function properties for _Z14comp_keys_compPtPjPyjS0_
1>      16624 bytes stack frame, 344 bytes spill stores, 668 bytes spill loads
1>  ptxas info    : Used 63 registers, 72 bytes cmem[0], 28 bytes cmem[16]
1>  ptxas info    : Function properties for _Z10CheckPointPjiiiPtS_jS_i
1>      80 bytes stack frame, 28 bytes spill stores, 40 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetAddressiPjPc
1>      160 bytes stack frame, 4 bytes spill stores, 4 bytes spill loads
1>  ptxas info    : Function properties for _Z13CheckHashCompPtPyhiPjjS1_
1>      56 bytes stack frame, 36 bytes spill stores, 36 bytes spill loads
1>  ptxas info    : Function properties for _Z14_ModInvGroupedPA4_y
1>      16592 bytes stack frame, 308 bytes spill stores, 276 bytes spill loads
1>  ptxas info    : Function properties for _Z15_GetHash160CompPyhPh
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z6_MatchPKcS0_
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z7_ModInvPy
1>      96 bytes stack frame, 200 bytes spill stores, 204 bytes spill loads
1>  ptxas info    : Compiling entry function '_Z22comp_keys_p2sh_patternjPtPyjPj' for 'sm_20'
1>  ptxas info    : Function properties for _Z22comp_keys_p2sh_patternjPtPyjPj
1>      16752 bytes stack frame, 428 bytes spill stores, 868 bytes spill loads
1>  ptxas info    : Used 63 registers, 72 bytes cmem[0], 28 bytes cmem[16]
1>  ptxas info    : Function properties for _Z10CheckPointPjiiiPtS_jS_i
1>      72 bytes stack frame, 20 bytes spill stores, 20 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetAddressiPjPc
1>      160 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetHash160PyS_Ph
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z13CheckP2SHHashjPtPyS0_iPjjS1_
1>      48 bytes stack frame, 44 bytes spill stores, 44 bytes spill loads
1>  ptxas info    : Function properties for _Z14_ModInvGroupedPA4_y
1>      16592 bytes stack frame, 308 bytes spill stores, 276 bytes spill loads
1>  ptxas info    : Function properties for _Z15_GetHash160CompPyhPh
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z17CheckHashP2SHCompPtPyhiPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z19CheckHashP2SHUncompPtPyS0_iPjjS1_
1>      48 bytes stack frame, 28 bytes spill stores, 28 bytes spill loads
1>  ptxas info    : Function properties for _Z19_GetHash160P2SHCompPyhPh
1>      24 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z21_GetHash160P2SHUncompPyS_Ph
1>      24 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z6_MatchPKcS0_
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z7_ModInvPy
1>      96 bytes stack frame, 200 bytes spill stores, 204 bytes spill loads
1>  ptxas info    : Compiling entry function '_Z9comp_keysjPtPjPyjS0_' for 'sm_20'
1>  ptxas info    : Function properties for _Z9comp_keysjPtPjPyjS0_
1>      16752 bytes stack frame, 436 bytes spill stores, 852 bytes spill loads
1>  ptxas info    : Used 63 registers, 80 bytes cmem[0], 28 bytes cmem[16]
1>  ptxas info    : Function properties for _Z10CheckPointPjiiiPtS_jS_i
1>      72 bytes stack frame, 24 bytes spill stores, 28 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetAddressiPjPc
1>      160 bytes stack frame, 4 bytes spill stores, 4 bytes spill loads
1>  ptxas info    : Function properties for _Z11_GetHash160PyS_Ph
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z13CheckHashCompPtPyhiPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z14_ModInvGroupedPA4_y
1>      16592 bytes stack frame, 308 bytes spill stores, 276 bytes spill loads
1>  ptxas info    : Function properties for _Z15CheckHashUncompPtPyS0_iPjjS1_
1>      56 bytes stack frame, 32 bytes spill stores, 32 bytes spill loads
1>  ptxas info    : Function properties for _Z15_GetHash160CompPyhPh
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z6_MatchPKcS0_
1>      0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
1>  ptxas info    : Function properties for _Z7_ModInvPy
1>      96 bytes stack frame, 200 bytes spill stores, 204 bytes spill loads
1>  ptxas info    : Function properties for _Z9CheckHashjPtPyS0_iPjjS1_
1>      48 bytes stack frame, 44 bytes spill stores, 56 bytes spill loads
1>CUDACOMPILE : nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
1>  GPUEngine.cu
1>cl : Command line warning D9002: ignoring unknown option '/arch:SSE2'
1>  Base58.cpp
1>  Bech32.cpp
1>  GPUGenerate.cpp
1>  ripemd160.cpp
1>  ripemd160_sse.cpp
1>  sha256.cpp
1>  sha256_sse.cpp
1>  sha512.cpp
1>  Int.cpp
1>  IntGroup.cpp
1>  IntMod.cpp
1>  main.cpp
1>  Point.cpp
1>  Random.cpp
1>  SECP256K1.cpp
1>  Timer.cpp
1>  Vanity.cpp
1>  Generating Code...
1>Vanity.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl Wildcard::match(char const *,char const *,bool)" (?match@Wildcard@@SA_NPEBD0_N@Z)
1>C:\Users\VAIO\Downloads\appspot\full\x64\Release\VanitySearchCUDA8.exe : fatal error LNK1120: 1 unresolved externals
1>
1>Project Performance Summary:
1>    98084 ms  C:\Users\VAIO\Downloads\appspot\full\VanitySearchCUDA8.vcxproj   2 calls
1>              64434 ms  Build                                      1 calls
1>              33650 ms  CudaBuildCore                              1 calls
1>
1>Target Performance Summary:
1>        0 ms  ComputeMIDLGeneratedCompileInputs          1 calls
1>        0 ms  PlatformPrepareForBuild                    1 calls
1>        0 ms  AfterClCompile                             1 calls
1>        0 ms  BeforeBuildGenerateSources                 1 calls
1>        0 ms  _ResourceCompile                           1 calls
1>        0 ms  _PrepareForReferenceResolution             1 calls
1>        0 ms  PreLinkEvent                               1 calls
1>        0 ms  AfterMidl                                  1 calls
1>        0 ms  BeforeResourceCompile                      1 calls
1>        0 ms  ComputeLinkInputsFromProject               1 calls
1>        0 ms  ComputeManifestInputsTargets               1 calls
1>        0 ms  ComputeCLInputPDBName                      1 calls
1>        0 ms  BeforeLink                                 1 calls
1>        0 ms  ComputeManifestGeneratedLinkerInputs       1 calls
1>        0 ms  BuildLinkTraverse                          1 calls
1>        0 ms  ComputeRCOutputs                           1 calls
1>        0 ms  ModifyUnitTestPlatformVersion              1 calls
1>        0 ms  GetReferenceAssemblyPaths                  1 calls
1>        0 ms  ExpandSDKReferences                        1 calls
1>        0 ms  _ClCompile                                 1 calls
1>        0 ms  SelectCustomBuild                          1 calls
1>        0 ms  BuildCompile                               1 calls
1>        0 ms  _Midl                                      1 calls
1>        0 ms  _PrepareForBuild                           1 calls
1>        0 ms  BuildCompileTraverse                       1 calls
1>        0 ms  GetResolvedWinMD                           1 calls
1>        0 ms  SelectClCompile                            1 calls
1>        0 ms  CreateCustomManifestResourceNames          1 calls
1>        0 ms  _BuildCompileAction                        1 calls
1>        0 ms  GetInstalledSDKLocations                   1 calls
1>        0 ms  BuildGenerateSources                       1 calls
1>        0 ms  AfterResourceCompile                       1 calls
1>        0 ms  ComputeLegacyManifestEmbedding             1 calls
1>        0 ms  ResolveReferences                          1 calls
1>        0 ms  BuildGenerateSourcesTraverse               1 calls
1>        0 ms  _SplitProjectReferencesByFileExistence     1 calls
1>        0 ms  ResolveProjectReferences                   1 calls
1>        0 ms  ComputeCLGeneratedLinkInputs               1 calls
1>        0 ms  PrepareForCudaBuild                        2 calls
1>        0 ms  _Xsd                                       1 calls
1>        0 ms  ResolveSDKReferences                       1 calls
1>        0 ms  _BuildGenerateSourcesAction                1 calls
1>        0 ms  ComputeCustomBuildOutput                   1 calls
1>        0 ms  ComputeLinkSwitches                        1 calls
1>        0 ms  AfterBuildGenerateSources                  1 calls
1>        0 ms  BeforeClCompile                            1 calls
1>        0 ms  MakeDirsForResourceCompile                 1 calls
1>        0 ms  PreBuildEvent                              1 calls
1>        0 ms  ComputeRCGeneratedLinkInputs               1 calls
1>        0 ms  AfterBuildCompileEvent                     1 calls
1>        0 ms  PrepareResourceNames                       1 calls
1>        0 ms  BeforeResolveReferences                    1 calls
1>        0 ms  AfterResolveReferences                     1 calls
1>        0 ms  _SelectedFiles                             1 calls
1>        0 ms  MakeDirsForMidl                            1 calls
1>        0 ms  AfterBuildGenerateSourcesEvent             1 calls
1>        1 ms  ResolveAssemblyReferences                  1 calls
1>        1 ms  ValidateCudaCodeGeneration                 1 calls
1>        1 ms  DoLinkOutputFilesMatch                     1 calls
1>        1 ms  ComputeReferenceCLInput                    1 calls
1>        1 ms  MakeDirsForCl                              1 calls
1>        1 ms  InitializeCudaProjectProperties            1 calls
1>        1 ms  ComputeCudaCompileOutput                   1 calls
1>        1 ms  AssignProjectConfiguration                 1 calls
1>        1 ms  InitializeCudaHostProperties               1 calls
1>        1 ms  Desktop_PlatformPrepareForBuild            1 calls
1>        1 ms  SplitResourcesByCulture                    1 calls
1>        1 ms  FixupCLCompileOptions                      1 calls
1>        1 ms  MakeDirsForLink                            1 calls
1>        1 ms  AddCudaLinkMetadata                        1 calls
1>        1 ms  GetFrameworkPaths                          1 calls
1>        1 ms  AssignTargetPaths                          1 calls
1>        1 ms  ValidateCudaBuild                          1 calls
1>        2 ms  AddCudaCompileMetadata                     1 calls
1>        2 ms  ComputeCLOutputs                           1 calls
1>        3 ms  SetBuildDefaultEnvironmentVariables        2 calls
1>        4 ms  _CheckForInvalidConfigurationAndPlatform   2 calls
1>        5 ms  InitializeBuildStatus                      1 calls
1>        6 ms  PrepareForBuild                            1 calls
1>        8 ms  AddCudaCompilePropsDeps                    1 calls
1>       10 ms  WarnCompileDuplicatedFilename              1 calls
1>       14 ms  SetCABuildNativeEnvironmentVariables       1 calls
1>      861 ms  Link                                       1 calls
1>    10804 ms  AddCudaCompileDeps                         1 calls
1>    18936 ms  ClCompile                                  1 calls
1>    33648 ms  CudaBuildCore                              1 calls
1>    33757 ms  CudaBuild                                  1 calls
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I use:
- Windows 10 [newest ver. 1909]
- CUDA 8.0 GA2 (latest version CUDA 8.0)
- Visual Studio 2015 Community
- Windows SDK 10.0.17763.0

[Jean_Luc]

It seems that you project file (.vcxproj) is not up to date. Wildcard.cpp is missing.
I see that the vcxproj for CUDA8 is not up to date on the git repo. vcxproj for CUDA10 is ok.

[Jean_Luc]

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

[Firebox]

@Jean_Luc
Could you issue new releases with new features more often? See some people have a difficulty to build it.
Let it be beta releases.... why not? ))

[Jean_Luc]

I published a new release. 1.16.
It is now possible to specify freely a grid size and increase performance on certain GPU.

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -gpu 1TestMe
VanitySearch v1.16
Difficulty: 888446610539
Search: 1TestMe [Compressed]
Start Tue Jan  7 09:25:30 2020
Base Key: 2AC862CEC11BB2E15C5D864CEF26D3E0640BEA49DA58C4E96F1339B84E466C78
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
[221.77 Mkey/s][GPU 221.77 Mkey/s][Total 2^30.72][Prob 0.2%][50% in 00:46:08][Found 0]

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -gpu -g 48,256 1TestMe
VanitySearch v1.16
Difficulty: 888446610539
Search: 1TestMe [Compressed]
Start Tue Jan  7 09:25:52 2020
Base Key: CB77C0255E5A334DCFA5B8788EB0FF6A04EBE360AA13A4D17A114E07EADCCD9F
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x256)
[271.78 Mkey/s][GPU 271.78 Mkey/s][Total 2^31.34][Prob 0.3%][50% in 00:37:35][Found 0]

[bangbumbang]

Hey
@Jean_Luc
first of all great work man!!! Th@nX 4 that.

i am getting CUDA errors though when trying to load more than a few addresses from a file, 5 or 6 work fine but over 100 - error

./VanitySearch -t 0 -gpu -gpuId 0,1 -b -o found.txt -i 150.txt
[Loading input file 100.0%]
VanitySearch v1.16
[Building lookup16 100.0%]
[Building lookup32 100.0%]
Search: 21910565 addresses (Lookup size 65536,[259,3090]) [Compressed or Uncompressed]
Start Tue Jan  7 13:30:08 2020
Base Key: C35B40E791110DE6D0F50C9578EA671F85F32B736E924F285967428735499924
Number of CPU thread: 0
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

i am an ubuntu 18 and did "make gpu=1 ccap=75 all"
everything seems to be working otherwise.. -check reports no errors prefix search no errors and as mentioned a few addresses also no error.
in version 1.15 it was the same ... I tried both today..
don't really know what to do here.. haven't done Cuda programming myself.. at least not jet so debugging this is a little out of my scope 4 now.
I did try to search on this threat but... well didn't find anything that helped me here..

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?

[cryptoroy]

I published a new release. 1.16.
It is now possible to specify freely a grid size and increase performance on certain GPU.

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -gpu 1TestMe
VanitySearch v1.16
Difficulty: 888446610539
Search: 1TestMe [Compressed]
Start Tue Jan  7 09:25:30 2020
Base Key: 2AC862CEC11BB2E15C5D864CEF26D3E0640BEA49DA58C4E96F1339B84E466C78
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
[221.77 Mkey/s][GPU 221.77 Mkey/s][Total 2^30.72][Prob 0.2%][50% in 00:46:08][Found 0]

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -t 0 -gpu -g 48,256 1TestMe
VanitySearch v1.16
Difficulty: 888446610539
Search: 1TestMe [Compressed]
Start Tue Jan  7 09:25:52 2020
Base Key: CB77C0255E5A334DCFA5B8788EB0FF6A04EBE360AA13A4D17A114E07EADCCD9F
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x256)
[271.78 Mkey/s][GPU 271.78 Mkey/s][Total 2^31.34][Prob 0.3%][50% in 00:37:35][Found 0]

Hi Jean_Luc, ++++ For your work.

Let me know if VanitySearch is able to find the key of an entire btc address!

Is the number of prefixes limited to 5 or 6 or 7?

thx

[Jean_Luc]

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