Hey,
i will use oclvanitygen but I get an error, i read 1 hours but i don't found the right solution.
i use Win7
AMD APP SDK\2.9 is installed
C:\Users\XX\Desktop\t
"calc_addrs.cl" is there
cmd, C:\Users\XX\Desktop\t\oclvanitygen.exe -d 0 -i Hello
error loading kernel file 'calc_addrs.cl': No such file or directory
so what I doing wrong
Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 75. (Read 1153383 times)
<<-- snip -->
Very valuable addition, thank you very much! I'll look into it at the end of the week, when I have more time again.
What results did you observe speed-wise?
The relative speed differences as posted in the code blocks stayed more or less the same
so ~ +10 % from compressed to uncompressed (no change compared to original code)
~ +60 % from uncompressed to combined
~ +50 % from compressed to combined
I see no reason why these relative speed increases would not work in OpenCL.
As stated before, this was interesting to research.
Unfortunately I don't have a OpenCL environment, so I made the adaptations for CPU only
hashing both the Uncompressed and Compressed EC-point.
With my hack, I'm losing some time on the normal and compressed code execution due to selection overhead.
I'll update my repo @ github after some code cleaning :-)
Update: Github repro updated
Unfortunately I don't have a OpenCL environment, so I made the adaptations for CPU only
Code:
>~/vanitygen$ ./vanitygen 1BTC4me --> normal uncompressed
Difficulty: 15058417127
[531.70 Kkey/s][total 5206528][Prob 0.0%][50% in 5.5h]
[533.98 Kkey/s][total 6267648][Prob 0.0%][50% in 5.4h]
>~/vanitygen$ ./vanitygen 1BTC4me -F compressed --> compressed
Difficulty: 15058417127
[616.63 Kkey/s][total 6103808][Prob 0.0%][50% in 4.7h]
[610.36 Kkey/s][total 7794688][Prob 0.1%][50% in 4.7h]
>~/vanitygen$ ./vanitygen 1BTC4me -F combined --> combined un/compressed
Difficulty: 15058417127
[837.12 Kkey/s][total 8072704][Prob 0.1%][50% in 3.5h]
[843.84 Kkey/s][total 8910848][Prob 0.1%][50% in 3.4h]
Difficulty: 15058417127
[531.70 Kkey/s][total 5206528][Prob 0.0%][50% in 5.5h]
[533.98 Kkey/s][total 6267648][Prob 0.0%][50% in 5.4h]
>~/vanitygen$ ./vanitygen 1BTC4me -F compressed --> compressed
Difficulty: 15058417127
[616.63 Kkey/s][total 6103808][Prob 0.0%][50% in 4.7h]
[610.36 Kkey/s][total 7794688][Prob 0.1%][50% in 4.7h]
>~/vanitygen$ ./vanitygen 1BTC4me -F combined --> combined un/compressed
Difficulty: 15058417127
[837.12 Kkey/s][total 8072704][Prob 0.1%][50% in 3.5h]
[843.84 Kkey/s][total 8910848][Prob 0.1%][50% in 3.4h]
Code:
>~/vanitygen$ ./vanitygen 1BTC4 -F combined -k
Difficulty: 4476342
Pattern: 1BTC4
Address: 1BTC4iPDG4247a3nmcnUTcLNS1bbwYRgvJ
Privkey: 5J85mEv3tk1HjYBCm6bcKHVEV9NjwtxFg2cVfY6SnhjW616VBvv --> uncompressed result
Pattern: 1BTC4
Address: 1BTC4pnrA9jnJB3usxhaVs4wweQtpcQ7a7
Privkey: KwJX5idP7UVGHQbL1QZRzjPcgYnXv6AkRsBhmuDzhJfvmASRZBQT --> compressed result
Pattern: 1BTC4
Address: 1BTC4caZJqqGZzjEdpbXuX17wyQgv4oRpK
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1Sevj3RoxkhoL3Q
Pattern: 1BTC4
Address: 1BTC4tkVwqUTCmG5fYexRyAaby3UXyt79R
Privkey: 5HqNmZzdjFPGF94hZGJmdeFBoa2hzLkShXQGajeP8n9CoEz8SzJ
Pattern: 1BTC4
Address: 1BTC4fZk5atAnE7DH6qW3mjP3AdikkNM6Z
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1SevmVBzAzN6BMR
If you don't mind if the WIF key is compressed or not, there is a substantiation speed increase whenDifficulty: 4476342
Pattern: 1BTC4
Address: 1BTC4iPDG4247a3nmcnUTcLNS1bbwYRgvJ
Privkey: 5J85mEv3tk1HjYBCm6bcKHVEV9NjwtxFg2cVfY6SnhjW616VBvv --> uncompressed result
Pattern: 1BTC4
Address: 1BTC4pnrA9jnJB3usxhaVs4wweQtpcQ7a7
Privkey: KwJX5idP7UVGHQbL1QZRzjPcgYnXv6AkRsBhmuDzhJfvmASRZBQT --> compressed result
Pattern: 1BTC4
Address: 1BTC4caZJqqGZzjEdpbXuX17wyQgv4oRpK
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1Sevj3RoxkhoL3Q
Pattern: 1BTC4
Address: 1BTC4tkVwqUTCmG5fYexRyAaby3UXyt79R
Privkey: 5HqNmZzdjFPGF94hZGJmdeFBoa2hzLkShXQGajeP8n9CoEz8SzJ
Pattern: 1BTC4
Address: 1BTC4fZk5atAnE7DH6qW3mjP3AdikkNM6Z
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1SevmVBzAzN6BMR
hashing both the Uncompressed and Compressed EC-point.
With my hack, I'm losing some time on the normal and compressed code execution due to selection overhead.
I'll update my repo @ github after some code cleaning :-)
Update: Github repro updated
Very valuable addition, thank you very much! I'll look into it at the end of the week, when I have more time again.
What results did you observe speed-wise?
Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
= peachy
I have an R9 390 but I'm using the opensource radeon stack.
samr7's version craps out so I tried the fork of the fella with the
handle of WyseNynja.
Does anyone know if there is another vanitygen fork I can try.
I wonder if the amdgpu stack will work ...
build log here http://dpaste.com/3X44N1Z
Code:
milton@milton:~/temp/vanitygen$ ./vanitygen -v 1xeon
Prefix difficulty: 264104224 1xeon
Difficulty: 264104224
Using 16 worker thread(s)
[2.67 Mkey/s][total 25884672][Prob 9.3%][50% in 58.9s]
Prefix difficulty: 264104224 1xeon
Difficulty: 264104224
Using 16 worker thread(s)
[2.67 Mkey/s][total 25884672][Prob 9.3%][50% in 58.9s]
= peachy
I have an R9 390 but I'm using the opensource radeon stack.
samr7's version craps out so I tried the fork of the fella with the
handle of WyseNynja.
Code:
milton@milton:~/temp/testing/vanitygen$ ./oclvanitygen 1xeon
Difficulty: 264104224
[16.09 Mkey/s][total 752353280][Prob 94.2%][95% in 2.4s] clWaitForEvent(clUnmapMemObject,4): CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST
Device: AMD HAWAII (DRM 2.42.0, LLVM 3.6.2)
Vendor: AMD (1002)
Driver: 11.0.0-devel
Profile: FULL_PROFILE
Version: OpenCL 1.1 MESA 11.0.0-devel
Max compute units: 40
Max workgroup size: 256
Global memory: 1073741824
Max allocation: 268435456
[16.09 Mkey/s][total 935854080][Prob 97.1%] clWaitForEvents(NDRange,1): CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST
Difficulty: 264104224
[16.09 Mkey/s][total 752353280][Prob 94.2%][95% in 2.4s] clWaitForEvent(clUnmapMemObject,4): CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST
Device: AMD HAWAII (DRM 2.42.0, LLVM 3.6.2)
Vendor: AMD (1002)
Driver: 11.0.0-devel
Profile: FULL_PROFILE
Version: OpenCL 1.1 MESA 11.0.0-devel
Max compute units: 40
Max workgroup size: 256
Global memory: 1073741824
Max allocation: 268435456
[16.09 Mkey/s][total 935854080][Prob 97.1%] clWaitForEvents(NDRange,1): CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST
Does anyone know if there is another vanitygen fork I can try.
I wonder if the amdgpu stack will work ...
build log here http://dpaste.com/3X44N1Z
I do not have time to read the whole thread. Can someone give me an idea and/or link to the maximum key generation rate claimed? It is for another thread...
But.. you no longer support vanity addresses... 
I haven' gone through the entire thread, I'd imagine there's some crazy SLI setup or so that'll go faster, but I did add the most recent reports to the wiki: https://en.bitcoin.it/wiki/Vanitygen#Expected_keysearch_rate
That page may also contain a hint for said other thread.
I do not have time to read the whole thread. Can someone give me an idea and/or link to the maximum key generation rate claimed? It is for another thread...
Does it? Specs-wise, it is a good bit faster than the HD5870. I can't say I know which specs' changes would best align with vanitygen changes, but it doesn't seem unfathomable. I'm sure it's not even removely the fastest; but hardware review sites don't generally test against oclvanitygen
I bought the 5870 when the R9s first came out, and it got swept by the HD5870s by about a 50% difference, as it did against the entire HD7xxx series.I can get 28MKeys/s with my Sapphire HD7970 and I recently acquired an ASUS Strix GTX 970 which gets 40+MKeys/s with much less power consumption.
edit: This post is used as reference for the Vanitygen Bitcoin Wiki page so I thought I would add a screen cap which shows the performance of my Asus Strix GTX 970
Could anybody post the necessary code changes to allow oclvanitygen to generate compressed and uncompressed keys simultaneously? I suspect the speed increase must be substantial
Thanks!
Your "suspicion" is misplaced. The only calculation in common that would be saved is the calculation of the x coordinate of the public key, which is just a few multiplications. Everything else, from creating the compressed public key parity, creating an address from a compressed public key and checking for the vanity match would be a completely different process.Thanks!
Unfortunately I don't have a OpenCL environment, so I made the adaptations for CPU only
Code:
>~/vanitygen$ ./vanitygen 1BTC4me --> normal uncompressed
Difficulty: 15058417127
[531.70 Kkey/s][total 5206528][Prob 0.0%][50% in 5.5h]
[533.98 Kkey/s][total 6267648][Prob 0.0%][50% in 5.4h]
>~/vanitygen$ ./vanitygen 1BTC4me -F compressed --> compressed
Difficulty: 15058417127
[616.63 Kkey/s][total 6103808][Prob 0.0%][50% in 4.7h]
[610.36 Kkey/s][total 7794688][Prob 0.1%][50% in 4.7h]
>~/vanitygen$ ./vanitygen 1BTC4me -F combined --> combined un/compressed
Difficulty: 15058417127
[837.12 Kkey/s][total 8072704][Prob 0.1%][50% in 3.5h]
[843.84 Kkey/s][total 8910848][Prob 0.1%][50% in 3.4h]
Difficulty: 15058417127
[531.70 Kkey/s][total 5206528][Prob 0.0%][50% in 5.5h]
[533.98 Kkey/s][total 6267648][Prob 0.0%][50% in 5.4h]
>~/vanitygen$ ./vanitygen 1BTC4me -F compressed --> compressed
Difficulty: 15058417127
[616.63 Kkey/s][total 6103808][Prob 0.0%][50% in 4.7h]
[610.36 Kkey/s][total 7794688][Prob 0.1%][50% in 4.7h]
>~/vanitygen$ ./vanitygen 1BTC4me -F combined --> combined un/compressed
Difficulty: 15058417127
[837.12 Kkey/s][total 8072704][Prob 0.1%][50% in 3.5h]
[843.84 Kkey/s][total 8910848][Prob 0.1%][50% in 3.4h]
Code:
>~/vanitygen$ ./vanitygen 1BTC4 -F combined -k
Difficulty: 4476342
Pattern: 1BTC4
Address: 1BTC4iPDG4247a3nmcnUTcLNS1bbwYRgvJ
Privkey: 5J85mEv3tk1HjYBCm6bcKHVEV9NjwtxFg2cVfY6SnhjW616VBvv --> uncompressed result
Pattern: 1BTC4
Address: 1BTC4pnrA9jnJB3usxhaVs4wweQtpcQ7a7
Privkey: KwJX5idP7UVGHQbL1QZRzjPcgYnXv6AkRsBhmuDzhJfvmASRZBQT --> compressed result
Pattern: 1BTC4
Address: 1BTC4caZJqqGZzjEdpbXuX17wyQgv4oRpK
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1Sevj3RoxkhoL3Q
Pattern: 1BTC4
Address: 1BTC4tkVwqUTCmG5fYexRyAaby3UXyt79R
Privkey: 5HqNmZzdjFPGF94hZGJmdeFBoa2hzLkShXQGajeP8n9CoEz8SzJ
Pattern: 1BTC4
Address: 1BTC4fZk5atAnE7DH6qW3mjP3AdikkNM6Z
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1SevmVBzAzN6BMR
If you don't mind if the WIF key is compressed or not, there is a substantiation speed increase whenDifficulty: 4476342
Pattern: 1BTC4
Address: 1BTC4iPDG4247a3nmcnUTcLNS1bbwYRgvJ
Privkey: 5J85mEv3tk1HjYBCm6bcKHVEV9NjwtxFg2cVfY6SnhjW616VBvv --> uncompressed result
Pattern: 1BTC4
Address: 1BTC4pnrA9jnJB3usxhaVs4wweQtpcQ7a7
Privkey: KwJX5idP7UVGHQbL1QZRzjPcgYnXv6AkRsBhmuDzhJfvmASRZBQT --> compressed result
Pattern: 1BTC4
Address: 1BTC4caZJqqGZzjEdpbXuX17wyQgv4oRpK
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1Sevj3RoxkhoL3Q
Pattern: 1BTC4
Address: 1BTC4tkVwqUTCmG5fYexRyAaby3UXyt79R
Privkey: 5HqNmZzdjFPGF94hZGJmdeFBoa2hzLkShXQGajeP8n9CoEz8SzJ
Pattern: 1BTC4
Address: 1BTC4fZk5atAnE7DH6qW3mjP3AdikkNM6Z
Privkey: KzNUxCmvVui8rLBFY4cMDy7TGeu5MDU7GSfPx1SevmVBzAzN6BMR
hashing both the Uncompressed and Compressed EC-point.
With my hack, I'm losing some time on the normal and compressed code execution due to selection overhead.
I'll update my repo @ github after some code cleaning :-)
Update: Github repro updated
Does it? Specs-wise, it is a good bit faster than the HD5870. I can't say I know which specs' changes would best align with vanitygen changes, but it doesn't seem unfathomable. I'm sure it's not even removely the fastest; but hardware review sites don't generally test against oclvanitygen
I bought the 5870 when the R9s first came out, and it got swept by the HD5870s by about a 50% difference, as it did against the entire HD7xxx series.
Does it? Specs-wise, it is a good bit faster than the HD5870. I can't say I know which specs' changes would best align with vanitygen changes, but it doesn't seem unfathomable. I'm sure it's not even removely the fastest; but hardware review sites don't generally test against oclvanitygen
Has the HD5870 been superseded yet as the best vanity miner? I bought mine for $100 and it gets a whopping 30Mkey/s out of the box. Have newer gen GFX cards surpassed this?
Claim of an nVidia GeForce GTX 780 Ti (3GB 384-bit GDDR5) getting 50-60Mkey/s: https://bitcointalksearch.org/topic/m.11944467Has the HD5870 been superseded yet as the best vanity miner? I bought mine for $100 and it gets a whopping 30Mkey/s out of the box. Have newer gen GFX cards surpassed this?
Claim of an nVidia GeForce GTX 780 Ti (3GB 384-bit GDDR5) getting 50-60Mkey/s: https://bitcointalksearch.org/topic/m.11944467
Has the HD5870 been superseded yet as the best vanity miner? I bought mine for $100 and it gets a whopping 30Mkey/s out of the box. Have newer gen GFX cards surpassed this?
No matter what I try, I couldnt make it work with OpenCL on my computer.
Did you update your video drivers? (Hint: Version 12.10 works best - saves Delta from stalking you in the middle of the night)
...and
Code:
-D 0:0 -D 0:1 etc
are your friends.......and
Code:
-S
safe mode may be fractionally slower, but it'll work until you've had some sleep.The only thing I'm not sure is if it searches for all lines listed or does them one at a time?
No matter what I try, I couldnt make it work with OpenCL on my computer.
How about telling us what didnt work and provide more information? Otherwise you wont get help.
No matter what I try, I couldnt make it work with OpenCL on my computer.
Given that there are two bitcoin addresses per private key, that if you are iterating through private keys pseudo-randomly (i assume this is what vanitygen does, at the end of the day), it does seem that you may as well look at both the addresses each time you calculate a point on the curve for a given private key...
Only the initial key position is random, then vanitygen just increments the key by one for each additional address search. There is little cost to be saved there.
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
I have 5 prefix letters , what is the command line for find at least a BTC address for it ?
Case-sensitive prefix search:
Code:
"path\to\vanitygen.exe" 1Prefix
Case-insensitive prefix search (faster):
Code:
"path\to\vanitygen.exe" -i 1Prefix
Case-sensitive prefix search but not limited to 1 match:
Code:
"path\to\vanitygen.exe" -k 1Prefix
Case-sensitive prefix search but not limited to 1 match and saves all matches to a file:
Code:
"path\to\vanitygen.exe" -k -o anything 1Prefix
Note: If you want to save all matches to a file in the same folder Vanitygen is, specify the path to directory. Eg:- "path\to\vanitygen.exe" -k -o "path\to\anything" 1za
Edit: Searching for compressed key is faster than uncompressed key. Download Lifeboat's vanitygen. See https://bitcointalksearch.org/topic/create-vanity-bitcoin-addresses-four-times-as-fast-301068. Also, see https://bitcointalksearch.org/topic/m.10590011.
Case-sensitive prefix search but not limited to 1 match and saves all matches to a file (compressed):
Code:
"path\to\vanitygen.exe" -k -F compressed -o anything 1Prefix
What are command lines for oclvanitygen ? does oclvanitygen use graphic card for computing ? and this is faster than vanitygen ?
Commands are same except you will have to select OpenCL device using -D command. If you have only one OpenCL device and you did not specify, Oclvanitygen automatically chooses the device. Else, it will give you an error.
Eg:-
Code:
"path\to\oclvanitygen.exe" -D 0:0 -k -o anything 1Prefix
-snip-
-snip-
-snip-
You know there's no BTC in this wallet https://blockchain.info/address/1Cii2e2wGejfrRHRCbaYTzmyPLpJwGvsgD (and it only every had about $50 at most ever?)
With a Quantum Computer, you'd be better off mining BitCoin blocks. 1,000 Billion is a Trillion BTW, thought you'd like to know that and a micro second... Well.... that's just silly....
With a Quantum Computer, you'd be better off mining BitCoin blocks. 1,000 Billion is a Trillion BTW, thought you'd like to know that and a micro second... Well.... that's just silly....
No, there's no known quantum algorithm for solving a SHA256 hash. It would also be useless for address reversal (except possibly with reused addresses) since the pubkey isn't known, just the hash, until the first spend from said address. I'm also not sure if EC is breakable on a quantum computer (Shor's algorithm has a discrete log variant but I'm not sure if it's applicable here)
tspacepilot it seems this is exactly what I was looking for. Could you tell me where to add the piece you posted?
Thanks!
Nice topic to research.Thanks!
the mayor changes will only have to be made in the function:
void *vg_thread_loop(void *arg).
In stead of the two options compress and uncompressed a combined flag could to be introduced/added as a valid command line flag.
When combined is active, only calculate (uncompressed) EC points for half the buffer.
Fill the other half with the equivalent compressed points.
for all other calculations use same flag to switch halfway between postprocessing (un)compressed settings.
The final address checks can stay the same.
In theory.... at least.
It will take a bit more work than just porting the example python code........
Jump to: