|
In any case this program is not designed to do that, so this is just tricks and you need to modify the code.
You have to disable the 5 optimized points, to set the startKey to 0 and specify a pub key or add the appropriate option.
You have also to adjust the starting key of each thread in order to cover the desired range.
This is more or less planned but not for the moment.
|
|
|
|
I ran with your file a bit, even tried to specify your grid size on my old Quadro and it worked. pons@linpons:~/VanitySearch$ ./VanitySearch -gpu -gpuId 0,1 -g 544,128,544,128 -i i133.txt
VanitySearch v1.16
Search: 133 addresses (Lookup size 133,[1,1]) [Compressed]
Start Thu Jan 9 15:38:20 2020
Base Key: 1A85D6F37BBEB28577F03B5329E3A2F0DE5D52A5A2781E266353544121CBA9BB
Number of CPU thread: 1
GPU: GPU #1 Quadro 600 (2x48 cores) Grid(544x128)
GPU: GPU #0 Quadro 600 (2x48 cores) Grid(544x128)
[55.40 Mkey/s][GPU 53.46 Mkey/s][Total 2^31.14][Prob 0.0%][50% in 5.79857e+32y][Found 0] ^C
Your git is up to date ? |
|
|
|
this happens with 133 addresses.. same thing after 3sec. but if it helps I can give you the 22 million file.. its about 750mb.. I was just Just send me the 133 addresses files via pm. May a particular address inside causes the issue. |
|
|
|
Search: 21910565 addresses (Lookup size 65536,[259,3090]) [Compressed or Uncompressed]
I never tried 21 million addresses as you, I have to generate such a list and see what will happen. 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?
VanitySearch.exe -l (it gives the ccap) |
|
|
|
At this moment the hash rate of bitcoin network is about 2^67 hashes/s, i.e. about 2^92 hashes/year.
The BTC network power is quite impressive ! Considering having the same power dedicated to address calculation, it would require few hours to find an address collision (2 private keys with the same address). |
|
|
|
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  |
|
|
|
|
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]
|
|
|
|
|
I just updated CUDA8 project files for VS2015.
Let me know if it is better...
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
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...
|
|
|
|
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 ? |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
Jean_Luc, thank you for the detailed explanation.
Do you know, are there any other elliptic curve properties exist besides symmetry and endomorphism?
Symmetry and endomorphism were used by you in the code to spead up the process. However may be you know some other properties or features which could be used for additional speedup?
To my knowledge, no other speedup using other ec properties can be added to VanitySearch, but my knowledge is not infinite  In any case the time required for ECC calculation is now low compare to hashing (~80% of CPU usage is taken by SHA256 and RIPEMD160). By using symmetry and endomorphism, we are near of ~1 modular multiplication per point. Even if we double the speed of ECC, it will only result in a ~10% speed increase. To my point of view, the only significant speedup can be bring by partial reversing of the hashing function in order to reduce hashing time consumption. |
|
|
|
Are these properties all known elliptic curve properties, or there are some other known properties but not used in vanitysearch?
Symmetry (x,y) (x,-y) is a common property of all elliptic curve. Secpk1 admit a primitive cubic root of unity so an endomorphism can be constructed using β and λ (β^3 = 1 mod p and λ^3 = 1 mod n) If β^3 = 1 and λ^3 = 1 we have also (β^-1)^3 = 1,(λ^-1)^3 = 1 so we can construct a second endomorphism using β^-1 and λ^-1. Note: β^3 = 1 mod p => β^3.(β^-1) = 1.(β^-1) mod p => β^2 = β^-1 mod p (same for λ^3 mod n) β = 7ae96a2b 657c0710 6e64479e ac3434e9 9cf04975 12f58995 c1396c28 719501ee
λ = 5363ad4c c05c30e0 a5261c02 8812645a 122e22ea 20816678 df02967c 1b23bd72
To find primitive roots of unity you need to factorize p-1 and n-1 and find common prime factors. We have always a primitive square root of unity but it is 1 and it does not bring an improvement, speck1 admit only a cubic primitive root of unity which can be exploited. Factorization of p-1 and n-1, only 3 can be exploited.
p-1 = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2E
2
3
7
3481
1DB8260E5E3B460A46A0088FCCF6A3A5936D75D89A776D4C0DA4F338AAFB
n-1 = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
2^6
3
95
277
17D6CFB8EE30C51
978C6F353C3889A79
10DBFF26EAB8198050172EE03275
I also made some tests with vanitysearch and it is interesting for me why it is faster than bitcrack. For example, for 1 compressed address on GTX 1080ti bitcrack has 340-350MKey/sec, but vanitysearch has 950-1000MKey/sec (3 times more). Was it caused by endomorphism used?
Symmetry and endomorphisms bring significant speedup. I'm not sure, but it seems to me that bitcrak use 32 bits arithmetic which is slower... Edit: Added factorisation of p-1 and n-1 |
|
|
|
I was very very busy during the last few months but now the the development is almost ended, we still have to debug few things, I'm starting to breath again |
|
|
|
|
Show Posts
