Bitcoin Forum
December 08, 2016, 08:34:59 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 809373 times)
r50zyry5
Jr. Member
*
Offline Offline

Activity: 30


View Profile
November 08, 2012, 09:59:15 PM
 #841

It's good params to run vanitygen on 4x 16 core opteron:
vanitygen -vi -t 1024 1ozyrys

I have:

Code:
Prefix difficulty:          27763956579 1ozyrys
Difficulty: 27763956579
Using 1024 worker thread(s)
[17.68 Mkey/s][total 97175808][Prob 0.3%][50% in 18.0min]

It's ok ?

Cheers
r50zyry5

p2pool Nodes
 *Image Removed*
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481229299
Hero Member
*
Offline Offline

Posts: 1481229299

View Profile Personal Message (Offline)

Ignore
1481229299
Reply with quote  #2

1481229299
Report to moderator
flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
November 08, 2012, 10:41:45 PM
 #842

So I saw a comment a while back about checking the compressed versions of the keys generated as well as the uncompressed versions and I've been playing with it a bit.  It gives me a roughly 80-90% speed increase in both vanitygen and oclvanitygen and so far I haven't found any problems with the addresses generated, the only difference is needing to import them as compressed (not that I've done a lot of testing with them outside of plugging them into bitaddress.org).  I did update vanitypool.thruhere.net to accept them as valid solutions (and promptly solved all the remaining work there) so unless someone submits more it isn't particularly useful for pool mining ATM (still getting half my work rejected by vanitypool.appspot.com but all the ones I have checked are correct, just compressed solutions it doesn't like).  It does however seem to be quite useful if you are searching for your own vanity addresses.

So what I have now is a very much hacked together version that works but is not particularly user-friendly (as in  I commented out most of the error-checking code to get it to return all the results from the GPU and you then have to take the private key and convert to the compressed address manually) but for anyone capable of working with that here is the changes I made to calc_addrs.cl to make it work (notice I only changed the CL prefix checker, not the return for regex)

Code:
1209c1209
< hash_ec_point(uint *hash_out, __global bn_word *xy, __global bn_word *zip)
---
> hash_ec_point(uint *hash_out, uint *chash_out, __global bn_word *xy, __global bn_word *zip)
1211c1211
<       uint hash1[16], hash2[16];
---
>       uint hash1[16], hash2[16], hash3[16], hash4[16];
1262a1263,1283
>
>       hash4[0] = hash1[0] ^ 0x06000000;
>       if(wh & 0x01){ hash4[0] ^= 0x01000000; }
>       hash4[1] = hash1[1];
>       hash4[2] = hash1[2];
>       hash4[3] = hash1[3];
>       hash4[4] = hash1[4];
>       hash4[5] = hash1[5];
>       hash4[6] = hash1[6];
>       hash4[7] = hash1[7];
>       hash4[8] = (hash1[8] & 0xff000000) | 0x800000;
>       hash4[9] = 0;
>       hash4[10] = 0;
>       hash4[11] = 0;
>       hash4[12] = 0;
>       hash4[13] = 0;
>       hash4[14] = 0;
>       hash4[15] = 33 * 8;
>       sha2_256_init(hash3);
>       sha2_256_block(hash3, hash4);
>
1300a1322,1326
> #define chash_ec_point_inner_6(i)             \
>       hash3[i] = bswap32(hash3[i]);
>
>       hash256_unroll(chash_ec_point_inner_6);
>
1310a1337,1347
>
>       hash3[8] = bswap32(0x80000000);
>       hash3[9] = 0;
>       hash3[10] = 0;
>       hash3[11] = 0;
>       hash3[12] = 0;
>       hash3[13] = 0;
>       hash3[14] = 32 * 8;
>       hash3[15] = 0;
>       ripemd160_init(chash_out);
>       ripemd160_block(chash_out, hash3);
1318c1355
<       uint hash[5];
---
>       uint hash[5], chash[5];
1331c1368
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1376c1413
<       uint hash[5];
---
>       uint hash[5], chash[5];
1389c1426
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1417a1455,1480
>                       high = -1;
>               }
>       }
>
> #define chash_ec_point_search_prefix_inner_1(i)       \
>       chash[i] = bswap32(chash[i]);
>
>       hash160_unroll(chash_ec_point_search_prefix_inner_1);
>
>       /* Binary-search the target table for the hash we just computed */
>       for (high = ntargets - 1, low = 0, i = high >> 1;
>            high >= low;
>            i = low + ((high - low) >> 1)) {
>               p = hash160_ucmp_g(chash, &target_table[10*i]);
>               low = (p > 0) ? (i + 1) : low;
>               high = (p < 0) ? (i - 1) : high;
>               if (p == 0) {
>                       /* For debugging purposes, write the hash value */
>                       found[0] = ((get_global_id(1) * get_global_size(0)) +
>                                   get_global_id(0));
>                       found[1] = i;
>
> #define chash_ec_point_search_prefix_inner_2(i)       \
>                       found[i+2] = load_be32(chash[i]);
>
>                       hash160_unroll(chash_ec_point_search_prefix_inner_2);

I guess it was my comment? Glad that it inspired you! Very nice patch - I'll try it out as soon as I get a chance! Smiley

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
abbeytim
Sr. Member
****
Offline Offline

Activity: 333


View Profile
November 15, 2012, 04:43:30 AM
 #843

is there flags to use multiple gpus to worke together

kind of like (oclvanityminer.exe -d 0,1,2 ) to use device 0 1 2 if its possible let me know
fizzisist
Hero Member
*****
Offline Offline

Activity: 720



View Profile WWW
November 15, 2012, 04:55:19 AM
 #844

So I saw a comment a while back about checking the compressed versions of the keys generated as well as the uncompressed versions and I've been playing with it a bit.  It gives me a roughly 80-90% speed increase in both vanitygen and oclvanitygen and so far I haven't found any problems with the addresses generated, the only difference is needing to import them as compressed (not that I've done a lot of testing with them outside of plugging them into bitaddress.org).  I did update vanitypool.thruhere.net to accept them as valid solutions (and promptly solved all the remaining work there) so unless someone submits more it isn't particularly useful for pool mining ATM (still getting half my work rejected by vanitypool.appspot.com but all the ones I have checked are correct, just compressed solutions it doesn't like).  It does however seem to be quite useful if you are searching for your own vanity addresses.

So what I have now is a very much hacked together version that works but is not particularly user-friendly (as in  I commented out most of the error-checking code to get it to return all the results from the GPU and you then have to take the private key and convert to the compressed address manually) but for anyone capable of working with that here is the changes I made to calc_addrs.cl to make it work (notice I only changed the CL prefix checker, not the return for regex)

Awesome work! I haven't tried it out myself, but I'm very interested in this.

A question about vanitypool.thruhere.net. Do you have any documentation on that? How does one see the available work, for example? Does it follow the API expected by oclvanityminer? I'd love to delve more into this stuff. Ideally oclvanityminer should check that and the appspot one to see which has more valuable work.

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
November 15, 2012, 06:33:47 AM
 #845

So I saw a comment a while back about checking the compressed versions of the keys generated as well as the uncompressed versions and I've been playing with it a bit.  It gives me a roughly 80-90% speed increase in both vanitygen and oclvanitygen and so far I haven't found any problems with the addresses generated, the only difference is needing to import them as compressed (not that I've done a lot of testing with them outside of plugging them into bitaddress.org).  I did update vanitypool.thruhere.net to accept them as valid solutions (and promptly solved all the remaining work there) so unless someone submits more it isn't particularly useful for pool mining ATM (still getting half my work rejected by vanitypool.appspot.com but all the ones I have checked are correct, just compressed solutions it doesn't like).  It does however seem to be quite useful if you are searching for your own vanity addresses.

So what I have now is a very much hacked together version that works but is not particularly user-friendly (as in  I commented out most of the error-checking code to get it to return all the results from the GPU and you then have to take the private key and convert to the compressed address manually) but for anyone capable of working with that here is the changes I made to calc_addrs.cl to make it work (notice I only changed the CL prefix checker, not the return for regex)

Code:
1209c1209
< hash_ec_point(uint *hash_out, __global bn_word *xy, __global bn_word *zip)
---
> hash_ec_point(uint *hash_out, uint *chash_out, __global bn_word *xy, __global bn_word *zip)
1211c1211
<       uint hash1[16], hash2[16];
---
>       uint hash1[16], hash2[16], hash3[16], hash4[16];
1262a1263,1283
>
>       hash4[0] = hash1[0] ^ 0x06000000;
>       if(wh & 0x01){ hash4[0] ^= 0x01000000; }
>       hash4[1] = hash1[1];
>       hash4[2] = hash1[2];
>       hash4[3] = hash1[3];
>       hash4[4] = hash1[4];
>       hash4[5] = hash1[5];
>       hash4[6] = hash1[6];
>       hash4[7] = hash1[7];
>       hash4[8] = (hash1[8] & 0xff000000) | 0x800000;
>       hash4[9] = 0;
>       hash4[10] = 0;
>       hash4[11] = 0;
>       hash4[12] = 0;
>       hash4[13] = 0;
>       hash4[14] = 0;
>       hash4[15] = 33 * 8;
>       sha2_256_init(hash3);
>       sha2_256_block(hash3, hash4);
>
1300a1322,1326
> #define chash_ec_point_inner_6(i)             \
>       hash3[i] = bswap32(hash3[i]);
>
>       hash256_unroll(chash_ec_point_inner_6);
>
1310a1337,1347
>
>       hash3[8] = bswap32(0x80000000);
>       hash3[9] = 0;
>       hash3[10] = 0;
>       hash3[11] = 0;
>       hash3[12] = 0;
>       hash3[13] = 0;
>       hash3[14] = 32 * 8;
>       hash3[15] = 0;
>       ripemd160_init(chash_out);
>       ripemd160_block(chash_out, hash3);
1318c1355
<       uint hash[5];
---
>       uint hash[5], chash[5];
1331c1368
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1376c1413
<       uint hash[5];
---
>       uint hash[5], chash[5];
1389c1426
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1417a1455,1480
>                       high = -1;
>               }
>       }
>
> #define chash_ec_point_search_prefix_inner_1(i)       \
>       chash[i] = bswap32(chash[i]);
>
>       hash160_unroll(chash_ec_point_search_prefix_inner_1);
>
>       /* Binary-search the target table for the hash we just computed */
>       for (high = ntargets - 1, low = 0, i = high >> 1;
>            high >= low;
>            i = low + ((high - low) >> 1)) {
>               p = hash160_ucmp_g(chash, &target_table[10*i]);
>               low = (p > 0) ? (i + 1) : low;
>               high = (p < 0) ? (i - 1) : high;
>               if (p == 0) {
>                       /* For debugging purposes, write the hash value */
>                       found[0] = ((get_global_id(1) * get_global_size(0)) +
>                                   get_global_id(0));
>                       found[1] = i;
>
> #define chash_ec_point_search_prefix_inner_2(i)       \
>                       found[i+2] = load_be32(chash[i]);
>
>                       hash160_unroll(chash_ec_point_search_prefix_inner_2);

Noob question: how do I make these changes to calc_addrs.cl?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
November 15, 2012, 09:19:10 AM
 #846

So I saw a comment a while back about checking the compressed versions of the keys generated as well as the uncompressed versions and I've been playing with it a bit.  It gives me a roughly 80-90% speed increase in both vanitygen and oclvanitygen and so far I haven't found any problems with the addresses generated, the only difference is needing to import them as compressed (not that I've done a lot of testing with them outside of plugging them into bitaddress.org).  I did update vanitypool.thruhere.net to accept them as valid solutions (and promptly solved all the remaining work there) so unless someone submits more it isn't particularly useful for pool mining ATM (still getting half my work rejected by vanitypool.appspot.com but all the ones I have checked are correct, just compressed solutions it doesn't like).  It does however seem to be quite useful if you are searching for your own vanity addresses.

So what I have now is a very much hacked together version that works but is not particularly user-friendly (as in  I commented out most of the error-checking code to get it to return all the results from the GPU and you then have to take the private key and convert to the compressed address manually) but for anyone capable of working with that here is the changes I made to calc_addrs.cl to make it work (notice I only changed the CL prefix checker, not the return for regex)

Code:
1209c1209
< hash_ec_point(uint *hash_out, __global bn_word *xy, __global bn_word *zip)
---
> hash_ec_point(uint *hash_out, uint *chash_out, __global bn_word *xy, __global bn_word *zip)
1211c1211
<       uint hash1[16], hash2[16];
---
>       uint hash1[16], hash2[16], hash3[16], hash4[16];
1262a1263,1283
>
>       hash4[0] = hash1[0] ^ 0x06000000;
>       if(wh & 0x01){ hash4[0] ^= 0x01000000; }
>       hash4[1] = hash1[1];
>       hash4[2] = hash1[2];
>       hash4[3] = hash1[3];
>       hash4[4] = hash1[4];
>       hash4[5] = hash1[5];
>       hash4[6] = hash1[6];
>       hash4[7] = hash1[7];
>       hash4[8] = (hash1[8] & 0xff000000) | 0x800000;
>       hash4[9] = 0;
>       hash4[10] = 0;
>       hash4[11] = 0;
>       hash4[12] = 0;
>       hash4[13] = 0;
>       hash4[14] = 0;
>       hash4[15] = 33 * 8;
>       sha2_256_init(hash3);
>       sha2_256_block(hash3, hash4);
>
1300a1322,1326
> #define chash_ec_point_inner_6(i)             \
>       hash3[i] = bswap32(hash3[i]);
>
>       hash256_unroll(chash_ec_point_inner_6);
>
1310a1337,1347
>
>       hash3[8] = bswap32(0x80000000);
>       hash3[9] = 0;
>       hash3[10] = 0;
>       hash3[11] = 0;
>       hash3[12] = 0;
>       hash3[13] = 0;
>       hash3[14] = 32 * 8;
>       hash3[15] = 0;
>       ripemd160_init(chash_out);
>       ripemd160_block(chash_out, hash3);
1318c1355
<       uint hash[5];
---
>       uint hash[5], chash[5];
1331c1368
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1376c1413
<       uint hash[5];
---
>       uint hash[5], chash[5];
1389c1426
<       hash_ec_point(hash, points_in, z_heap);
---
>       hash_ec_point(hash, chash, points_in, z_heap);
1417a1455,1480
>                       high = -1;
>               }
>       }
>
> #define chash_ec_point_search_prefix_inner_1(i)       \
>       chash[i] = bswap32(chash[i]);
>
>       hash160_unroll(chash_ec_point_search_prefix_inner_1);
>
>       /* Binary-search the target table for the hash we just computed */
>       for (high = ntargets - 1, low = 0, i = high >> 1;
>            high >= low;
>            i = low + ((high - low) >> 1)) {
>               p = hash160_ucmp_g(chash, &target_table[10*i]);
>               low = (p > 0) ? (i + 1) : low;
>               high = (p < 0) ? (i - 1) : high;
>               if (p == 0) {
>                       /* For debugging purposes, write the hash value */
>                       found[0] = ((get_global_id(1) * get_global_size(0)) +
>                                   get_global_id(0));
>                       found[1] = i;
>
> #define chash_ec_point_search_prefix_inner_2(i)       \
>                       found[i+2] = load_be32(chash[i]);
>
>                       hash160_unroll(chash_ec_point_search_prefix_inner_2);

Noob question: how do I make these changes to calc_addrs.cl?
use "patch < nameofpatchfile"

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
November 15, 2012, 05:39:37 PM
 #847

use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
November 15, 2012, 05:50:30 PM
 #848

use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this?

Have you tried this?

You are in a maze of twisty little passages, all alike.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
November 15, 2012, 05:52:22 PM
 #849

use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this?
Have you tried this?
Lol yes, that was what I tried first. http://stackoverflow.com/questions/517257/how-do-i-apply-a-diff-patch-on-windows Didn't really help me any.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
November 15, 2012, 06:11:53 PM
 #850

It's few enough lines changed that you could just hand edit to add the changes.

You are in a maze of twisty little passages, all alike.
mskwik
Full Member
***
Offline Offline

Activity: 125


View Profile
November 15, 2012, 06:13:08 PM
 #851

Here http://www.bitbin.it/TCUrsCoR is what mine looks like in its entirety, not sure how close to the current one with vanitygen the base was when I started, my whole vanitygen directory has been rather heavily modified and I haven't had a chance to try and rebase against the current version to get a clean patch.

Also note that changing the .cl file alone will just give what appear to be a bunch of hardware errors when it finds a compressed solution.  For testing purposes on mine I have just disabled the hardware error checking completely (which is a bad idea, I did purposely leave off detailed instructions on doing it because if you can't figure out how you probably shouldn't be playing with it), but basically it involves replacing the memcmp after the "/* Make sure the GPU produced the expected hash */" comment with a memcpy and adjusting the logic in oclvanitygen.c and recompiling (unless there's some switch to disable it now, again this is based off an older version).

K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
November 15, 2012, 10:45:32 PM
 #852

use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this?
i dont support Winblow$ unless u pay me Tongue

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
kuzetsa
Sr. Member
****
Offline Offline

Activity: 369


View Profile
November 17, 2012, 05:54:04 AM
 #853

So I wanted a palindrome in my bitcoin address:

Code:
vanitygen64 -r -k (.)(.).\2\1
vanitygen64 -r -k (.)(.)(.).\3\2\1
vanitygen64 -r -k (.)(.)(.)(.).\4\3\2\1
vanitygen64 -r -k (.)(.)(.)(.)(.).\5\4\3\2\1
vanitygen64 -r -k (.)(.)(.)(.)(.)(.).\6\5\4\3\2\1
vanitygen64 -r -k (.)(.)(.)(.)(.)(.)(.).\7\6\5\4\3\2\1

the 5 and 7 character palindrome is trivial, but with four or more backreferences, I get this:

Quote
CRE error: 0



Edited to add:

I went looking for the source to see about debugging the cre / pcre problems (if only be allowing more memory or heap space or whatever... this is a known compile-time difference between real perl and PCRE library)

Code:
vanitygen-master.zip
size: 89731 bytes
CRC32: CC22C3C1
MD5: 7DC5FE247AB21651EF14E5CCD201C125
SHA-1: 202EA5824B33D483F267077FB45159B63737ED8A

^grabbed source from the github, everything seems to be dated october 24th 2012...

1) I'm trying to figure out why there is no vanitygen64.exe make target in the makefile / windows version of makefile, etc.

2) Wondering what the recommended toolchain for building this is... I was planning to just use msys environment / mingw gcc since it's fairly standard

3) Noticed some of the hardcoded paths, specifically C:\OpenSSL-Win32, and was wondering which openssl was used... is official / vanilla / mainstream openssl-1.0.1c really what is being used? I'm having a bit of confusion with this more than anything, because there is no folder in the official / vanilla / mainstream openssl-1.0.1c source tarball named OpenSSL-Win32
deadweasel
Sr. Member
****
Offline Offline

Activity: 364



View Profile
November 23, 2012, 09:13:06 PM
 #854

When I run the command line:
oclvanityminer -u https://vanitypool.appspot.com/ -a 1XXXXXZTzBssUq6bnE27cz4rv5SJ4sr5

to generate addresses, it returns a list of my available OpenCL platforms.  It's my Processor and my graphics card.  then it simply stops running.  I am running this in the command line.

"
C:\Program Files\OCLVANITYMINER>oclvanityminer -u https://vanitypool.appspot.com
/ -a 1GdtkZzhZTzBssUq6bnE27cz4rv5SJ4sr5
Available OpenCL platforms:
0: [Advanced Micro Devices, Inc.] AMD Accelerated Parallel Processing
  0: [Advanced Micro Devices, Inc.] Juniper
  1: [AuthenticAMD] AMD Phenom(tm) II X4 925 Processor
"

Is there some documentation I'm missing to make it run? 

many thanks!

stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
November 23, 2012, 09:20:33 PM
 #855


oclvanityminer -u https://vanitypool.appspot.com/ -a 1XXXXXZTzBssUq6bnE27cz4rv5SJ4sr5


oclvanityminer -u https://vanitypool.appspot.com/ -a 1XXXXXZTzBssUq6bnE27cz4rv5SJ4sr5 -d 0

There ya go hun.

You are in a maze of twisty little passages, all alike.
deadweasel
Sr. Member
****
Offline Offline

Activity: 364



View Profile
November 23, 2012, 10:11:48 PM
 #856

Many thanks, kind sir!   Is there a spot where this is all documented?

Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
November 24, 2012, 02:29:57 AM
 #857

Many thanks, kind sir!   Is there a spot where this is all documented?
Most command line applications have a "--help" flag that will show you all the flags with a short description.

jtibble
Jr. Member
*
Offline Offline

Activity: 52



View Profile WWW
November 24, 2012, 06:29:42 PM
 #858

After running for about 15 hours on my GTX 460, it exploded and crashed my display driver with the following message:

Code:
oclvanitygen.exe 1jtibbs
Difficulty: 888446610538
[13.18 Mkey/s][total 670354112512][Prob 53.0%][75% in 11.8h]                   c
lWaitForEvents(NDRange,1): CL_OUT_OF_RESOURCES
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on GeF
orce GTX 460 (Device 0).

vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error executing CL_COMMAND_MA
P_BUFFER on GeForce GTX 460 (Device 0).

clEnqueueMapBuffer(4): CL_OUT_OF_RESOURCES
Device: GeForce GTX 460
Vendor: NVIDIA Corporation (10de)
Driver: 306.97
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 7
Max workgroup size: 1024
Global memory: 1073414144
Max allocation: 268353536
Device: GeForce GTX 460
Vendor: NVIDIA Corporation (10de)
Driver: 306.97
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 7
Max workgroup size: 1024
Global memory: 1073414144
Max allocation: 268353536
ERROR: Could not map row buffer for slot 1
ERROR: allocation failure?
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on GeF
orce GTX 460 (Device 0).

Any thoughts? This was with the most recent version.

Michael_S
Sr. Member
****
Offline Offline

Activity: 277


Bitcoin-Note-and-Voucher-Printing-Empowerer


View Profile
November 30, 2012, 04:53:23 AM
 #859

when using the -P option, vanitygen wants to know the public key in hex format after the -P, and specifying only the bitcoin address is not sufficient.

Is there any way to generate the public key in hex format from the bitcoin address alone?

If not, are other methods (no vanitygen, but similar methods) known that work the same way when only the bitcoin address, but not the hex format public key is known?


salfter
Hero Member
*****
Offline Offline

Activity: 550


My PGP Key: 92C7689C


View Profile WWW
November 30, 2012, 03:28:00 PM
 #860

use "patch < nameofpatchfile"
I'm on Win7. Is there a way for me to still do this?

  • Get Cygwin.
  • Use its installer to install patchutils (listed under "Devel").
  • Open a Cygwin prompt (looks like the usual command prompt, but has a real shell behind it...usually bash).
  • Proceed as you would with a real OS.  Grin

My Bitgem Pool - PPLNS, Stratum | Gridseed Miners - $25 off your first order | BTG Explorer
Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR BTG gTipsVB9qmyYHuqMMKTuCYMHpfkUFBXKrZ | My Bitcoin Note Generator | Pyramining: 1 2 3 4 5
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 155 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!