Vanitygen: Vanity bitcoin address generator/miner [v0.22]

[JackH]

So is it fair to assume that getting a long address such as xxxxxxxxxxxxxxx is going to take very very long time and is out of the question for a regular cpu?

Is there an option to use mining equipment to create a vanity address? I got two FPGA boards that are pushing out very little BTC, and I may as well just use them to make a cool sounding BTC address instead. Possible?

It would be possible with an FPGA, but not your FPGA miner, which was specifically made for mining.

Mining iteratively changes four bytes in a 512 byte data set and hashes it twice using the SHA256() algorithm, it then compares the beginning of the resulting hash to see if it contains all zero bits, and returns the value of the hashed data that met the challenge. This is likely all the FPGA is programmed to do.

Bitcoin address requires multiple steps with different algorithms and different criteria:

Generate a cryptographically secure random 64 bit private key.
Iterate through multiple increments of this key.
For each iteration, generate a public bitcoin address from the key:

• Generate a ECDSA secp256k1 public key for the private key
• SHA256 hash the public key
• RipeMD160 hash the above result
• SHA256 hash the result twice to generate a checksum
• Convert to a Base58 address prefix

check result against all vanity criteria being searched for, if not, do it all again.

You can see this requires much more code and algorithms than mining. So no.

So what is our upper limit char wise with the current equipment we have (CPU/GPU) and the software to generate and utilize those processors (if such software is made). Are we below 6 chars? Or can we hit 8 at least?

[deepceleron]

...

• Generate a ECDSA secp256k1 public key for the private key
• SHA256 hash the public key
• RipeMD160 hash the above result
• SHA256 hash the result twice to generate a checksum
• Convert to a Base58 address prefix

check result against all vanity criteria being searched for, if not, do it all again.

You can see this requires much more code and algorithms than mining. So no.

Is this list accurate? (IHNRTFS)

Wouldn't it be more efficient to convert the target pattern into hex for a case sensitive search? For case insensitive it might be doable, but harder.

No, as a policy I only post inaccurate information.   It doesn't describe exactly how an address is constructed but the algorithm-intensive steps.

Data is stored in computers as bits and bytes and words, "convert to hex" is only for the benefit of you viewing the data and doesn't have anything to do with how the underlying data is stored.

-The output of RIPEMD160 looks like this: 759d0e09aa7a865aaa8440bd0c6cf2a3fe2c038e - 160 bits. (in base 16)
-The base58 address looks like this: 31426974436f694e4d656554745344396e58325248766f5753325a4836414d676d6d (208-272 bits) (in base 16)
-The base58 address also looks like this: 1BitCoiNMeeTtSD9nX2RHvoWS2ZH6AMgmm (in base 256-the ASCII character set)

If you mean to examine the raw output of the hashing algorithms before conversion to Base58, that can't reveal your multiple phrase search, because the boundaries between address characters have no correspondence to the RIPEMD bytes.

If you have a specific case-sensitive single prefix you want to search for, you could save the address conversion step most of the time by reverse-base58-converting the beginning of a desired address, so that, for example if seeking the address above, you say you will only continue investigating if a pre-screen of the RIPEMD starts with 759d0e, corresponding approximately with 1BitCo... in the address. This however would be at the detriment of being able to search for multiple addresses and cases at once or seeking the phrase anywhere else but at the beginning.

So what is our upper limit char wise with the current equipment we have (CPU/GPU) and the software to generate and utilize those processors (if such software is made). Are we below 6 chars? Or can we hit 8 at least?

I think we can do at least 9 ↓

[scrybe]

...

If you mean to examine the raw output of the hashing algorithms before conversion to Base58, that can't reveal your multiple phrase search, because the boundaries between address characters have no correspondence to the RIPEMD bytes.

If you have a specific case-sensitive single prefix you want to search for, you could save the address conversion step most of the time by reverse-base58-converting the beginning of a desired address, so that, for example if seeking the address above, you say you will only continue investigating if a pre-screen of the RIPEMD starts with 759d0e, corresponding approximately with 1BitCo... in the address. This however would be at the detriment of being able to search for multiple addresses and cases at once or seeking the phrase anywhere else but at the beginning.

...

Yeah, I know bits, bytes, words, doublewords, quadwords, ASCII, EBCDIC, blocks, sectors, cylinders, tracks, and a host of other storage conventions from long experience, Reverse-Base58 encoded binary string would be more accurate (but a lot longer to say than "hex")

I was thinking of the case specific case sensitive (and solo) use case, being case insensitive or using multiple search strings would potentially not scale well. It depends on how a regex search gets unrolled during runtime evaluation compared to unrolling and reverse-base58 converting all the potential string combinations at startup and then just doing a scan (b-tree?) at runtime. You could even pre-compute the bit-shifted matches if you want to look deeper in the string than just the start.)

Honestly I don't know if this would have any impact at all, it would depend on how large and complex the potential namespace you are using for potential matches. OTOH, a Rainbow Table approach might be faster then what is there now.

Can you guys give me some idea what kinds of number of search strings folks are running concurrently?

[scrybe]

Can you guys give me some idea what kinds of number of search strings folks are running concurrently?

You mean like:
...
By the way, the search for the same phrase case-sensitive-only already goes 11% faster in oclvanitygen.

No, I was more looking for something like: "I have a file with 200 strings, 4-7 chars in length, case insensitive." If you focus on one name at a time with insensitivity that is 2 dimensions to put in the rainbow table (string variations * positional variations), adding multiple names takes it to 3. I was mostly wondering if folks search for lots of unique names (case sensitive or not) at the same time, or if the preference is to hit them one at a time.

Interesting about the 11%, that means that there is a quantifiable overhead related to the insensitive search, I'm assuming it scales with length? (have a link to some more numbers not buried on page 43 of a troll ridden thread? )

[JackH]

My plan is to generate a vanity address and buy the domain name. While I can be sure to get zero direct type ins for the domain, its going to be a cool trend to have your BTC vanity address as a domain name. Heck, ill buy the complementary Namecoin address for it.

[BkkCoins]

My plan is to generate a vanity address and buy the domain name. While I can be sure to get zero direct type ins for the domain, its going to be a cool trend to have your BTC vanity address as a domain name. Heck, ill buy the complementary Namecoin address for it.

You may want to choose one that you can get the FirstBits for as that would make a better domain name, one that actually could be typed in and have some meaning. See firstbits.com, check suitable prefixes there for one not owned, generate it with vanitygen and then send a small pmt to yourself to "own" the name.

[JackH]

My plan is to generate a vanity address and buy the domain name. While I can be sure to get zero direct type ins for the domain, its going to be a cool trend to have your BTC vanity address as a domain name. Heck, ill buy the complementary Namecoin address for it.

You may want to choose one that you can get the FirstBits for as that would make a better domain name, one that actually could be typed in and have some meaning. See firstbits.com, check suitable prefixes there for one not owned, generate it with vanitygen and then send a small pmt to yourself to "own" the name.

Nice tip man. Thank you very much.

[scrybe]

My plan is to generate a vanity address and buy the domain name. While I can be sure to get zero direct type ins for the domain, its going to be a cool trend to have your BTC vanity address as a domain name. Heck, ill buy the complementary Namecoin address for it.

You may want to choose one that you can get the FirstBits for as that would make a better domain name, one that actually could be typed in and have some meaning. See firstbits.com, check suitable prefixes there for one not owned, generate it with vanitygen and then send a small pmt to yourself to "own" the name.

Nice tip man. Thank you very much.

+1

[crazyates]

Very cool program, thanks samr7!

I had to use CPU since my GPU is a Pitcairn, has anyone got the 7k AMD series working through opencl yet?

It's kinda half-borked, but will work with the -S flag. It's much slower than it should be, but still faster than using a CPU.

[mskwik]

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

[r50zyry5]

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

[flatfly]

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!

[abbeytim]

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]

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]

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?

[K1773R]

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"

[crazyates]

use "patch < nameofpatchfile"

I'm on Win7. Is there a way for me to still do this?

[stevegee58]

use "patch < nameofpatchfile"

I'm on Win7. Is there a way for me to still do this?

Have you tried this?

[crazyates]

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.

[stevegee58]

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