Bitcoin Forum
May 30, 2020, 09:14:55 AM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 185 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1143694 times)
JackH
Sr. Member
****
Offline Offline

Activity: 381
Merit: 250


View Profile
November 02, 2012, 09:30:14 PM
 #821

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?

<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise
<helo> oh, you don't like a 20x increase? well how about 8192x increase?
<JackH> lmao
UNIQUE HILO GAME $500 DAILY CONTEST BEST AUTOBET MODE 30% RAKEBACK FOR VIPS PROVABLY FAIR Play Now Play Now
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1000



View Profile WWW
November 02, 2012, 09:50:10 PM
Last edit: November 02, 2012, 10:04:29 PM by deepceleron
 #822

...
  • 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.  Huh 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
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
November 02, 2012, 10:57:48 PM
 #823

...

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?

"...as simple as possible, but no simpler" -AE
BTC/TRC/FRC: 1ScrybeSNcjqgpPeYNgvdxANArqoC6i5u Ripple:rf9gutfmGB8CH39W2PCeRbLWMKRauYyVfx LTC:LadmiD6tXq7gFZvMibhFUZegUHKXgbu1Gb
scrybe
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
November 03, 2012, 12:56:09 AM
 #824


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


"...as simple as possible, but no simpler" -AE
BTC/TRC/FRC: 1ScrybeSNcjqgpPeYNgvdxANArqoC6i5u Ripple:rf9gutfmGB8CH39W2PCeRbLWMKRauYyVfx LTC:LadmiD6tXq7gFZvMibhFUZegUHKXgbu1Gb
JackH
Sr. Member
****
Offline Offline

Activity: 381
Merit: 250


View Profile
November 03, 2012, 10:57:07 AM
 #825

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.

<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise
<helo> oh, you don't like a 20x increase? well how about 8192x increase?
<JackH> lmao
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1002


firstbits:1MinerQ


View Profile WWW
November 03, 2012, 01:31:35 PM
 #826

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
Sr. Member
****
Offline Offline

Activity: 381
Merit: 250


View Profile
November 03, 2012, 02:30:20 PM
 #827

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.

<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise
<helo> oh, you don't like a 20x increase? well how about 8192x increase?
<JackH> lmao
scrybe
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
November 03, 2012, 07:44:03 PM
 #828

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

"...as simple as possible, but no simpler" -AE
BTC/TRC/FRC: 1ScrybeSNcjqgpPeYNgvdxANArqoC6i5u Ripple:rf9gutfmGB8CH39W2PCeRbLWMKRauYyVfx LTC:LadmiD6tXq7gFZvMibhFUZegUHKXgbu1Gb
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
November 05, 2012, 08:11:16 PM
 #829

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.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
November 08, 2012, 08:24:46 PM
 #830

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
Newbie
*
Offline Offline

Activity: 30
Merit: 0


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

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
Legendary
*
Offline Offline

Activity: 1008
Merit: 1006


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

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: 438
Merit: 250


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

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
Merit: 510



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

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: 952
Merit: 1000



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

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: 1792
Merit: 1008


/dev/null


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

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: 952
Merit: 1000



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

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
Legendary
*
Offline Offline

Activity: 921
Merit: 1003



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

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: 952
Merit: 1000



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

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
Legendary
*
Offline Offline

Activity: 921
Merit: 1003



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

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.
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 ... 185 »
  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!