Bitcoin Forum
December 06, 2016, 04:26:25 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 808857 times)
fizzisist
Hero Member
*****
Offline Offline

Activity: 720



View Profile WWW
October 31, 2012, 06:14:56 AM
 #821

question about the [50% in XXX] number.

when I run oclvanityminer i get one number for XXX, but if I manually plug in the public key and pattern to oclvanitygen, i get a very different XXX number. the one from oclvanityminer reports in "hours" while oclvanitygen reports in "years".

i haven't read this whole thread so i might missed it somewhere, but aren't those two values supposed to be the same since we're still basically solo mining with oclvanityminer?

Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.

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

Posts: 1481041585

View Profile Personal Message (Offline)

Ignore
1481041585
Reply with quote  #2

1481041585
Report to moderator
1481041585
Hero Member
*
Offline Offline

Posts: 1481041585

View Profile Personal Message (Offline)

Ignore
1481041585
Reply with quote  #2

1481041585
Report to moderator
cambda
Hero Member
*****
Offline Offline

Activity: 710

bitcoin makes the world a better place.


View Profile
October 31, 2012, 09:24:18 AM
 #822

question about the [50% in XXX] number.

when I run oclvanityminer i get one number for XXX, but if I manually plug in the public key and pattern to oclvanitygen, i get a very different XXX number. the one from oclvanityminer reports in "hours" while oclvanitygen reports in "years".

i haven't read this whole thread so i might missed it somewhere, but aren't those two values supposed to be the same since we're still basically solo mining with oclvanityminer?

Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.


First make sure GPU is used, you can see verbose output with -v
If CPU is used (much lower Key/s) use device specifier -d or -D  like -D 0:0 or -d 0

to list all patterns for a specific public key, use -f patternfile.txt
put in the file all patterns, one pattern per line

use -k to continue search after you found match

The speeds should be the same, i tried it myselves and i have the same speeds

kaerf
Hero Member
*****
Offline Offline

Activity: 631


View Profile
October 31, 2012, 05:02:17 PM
 #823


Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.

thanks. didn't know oclvanityminer had that feature already (i read somewhere in this thread that it was suggested).
Lurk
Full Member
***
Offline Offline

Activity: 126



View Profile
November 01, 2012, 08:25:01 PM
 #824

i have an old laptop   its saying it will take 42 days to generate the address....is this normal....and will it harm my computer?
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
November 02, 2012, 05:33:08 AM
 #825

i have an old laptop   its saying it will take 42 days to generate the address....is this normal....and will it harm my computer?
Depend on how fast you're hashing, and what address you're trying to find. I can find a 1xxx key in seconds, but a 1xxxxxxxx key would take years.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
scrybe
Sr. Member
****
Offline Offline

Activity: 350



View Profile
November 02, 2012, 06:01:12 AM
 #826

Very cool program, thanks samr7!

I got lucky and generated my first case sensitive 5 letter vanity address in 24 hours (50% in 9.3 days)

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

(no tips for now cause I'm illiquid in BTC, but I'll get you sometime after I get unlocked and working again.)

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

Activity: 355


View Profile
November 02, 2012, 08:19:33 PM
 #827

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?

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

Activity: 1470



View Profile WWW
November 02, 2012, 08:50:17 PM
 #828

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.

scrybe
Sr. Member
****
Offline Offline

Activity: 350



View Profile
November 02, 2012, 09:13:08 PM
 #829

...
  • 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.

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

Activity: 355


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

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

Activity: 1470



View Profile WWW
November 02, 2012, 09:50:10 PM
 #831

...
  • 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



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

...

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

Activity: 1470



View Profile WWW
November 02, 2012, 11:20:59 PM
 #833


Can you guys give me some idea what kinds of number of search strings folks are running concurrently?
You mean like:
Pattern: 1scrybe                                            
Address: 1SCRYbENkxMYAcxxxxpEMhuKLmrGuo9zH                  
Privkey: 5K9DXbi8e2n3f1xxxxLkXeXb8eZu4EDReK5yMHkvQjABrvkYgSq
Pattern: 1scrybe                                            
Address: 1SCrYbEuH46WJ4xxxxQJaSZdvcFoUxjEp                  
Privkey: 5KfVApp66N2XTVxxxxi5DrZPvrBboU9P2mEr6G8RhAYaftmK7Tp
Pattern: 1scrybe                                            
Address: 1scryBea3iUp2pxxxxoKv2Um75W2hsZfn                  
Privkey: 5JHdbsZHsHcKdAxxxxXadv95UKGtWSuCnNcXJhQFmLwSnamp9Gg
Pattern: 1scrybe                                            
Address: 1ScRYbewu9uvKoxxxxJ2zP8rxbeQV6pVa                  
Privkey: 5J9mA5RhW3HNvDxxxx8KjoaQjRXoN1Tw3rU1Yjt4CAZoJ3KhMvx
Pattern: 1scrybe                                            
Address: 1ScrYBeitmijfQxxxxiSXXyxX1962twpk                  
Privkey: 5Jt3QGFyVNhbN5xxxxewTzEnKT2Q67TPfhGzo1BND2EYa5iscgB
Pattern: 1scrybe                                            
Address: 1SCRYBeMKRuWFSxxxxxPhrkxbpGMU2dWv                  
Privkey: 5HrvsktKjrK3Voxxxx2gPxy5mYukSVWG13EGMhuwRV9trRwuV2R
Pattern: 1scrybe                                            
Address: 1scRYBEF3SY5sAxxxxRswDc7quPEW26xS                  
Privkey: 5JdETzAZ725nSxxxxxhmveS9RWQ1KyTR3puRBhLtm6SHnTRcGKg
Pattern: 1scrybe                                            
Address: 1SCrYbEegLHu4TxxxxwHGJfJC3ZyX3Kw7                  
Privkey: 5J3TcDrUy9b3ZCxxxxx8zUic7NyLuQVa3p9g8oMAThar9bSWiJ9
Pattern: 1scrybe                                            
Address: 1SCrYbeWDTQufhxxxx8AiTPFzkKsBCw6G                  
Privkey: 5Jxb7UN68SZrgJxxxxBkaCdEjR2vrn7Uof6W2i87wmEyKL1kzUc
Pattern: 1scrybe                                            
Address: 1scRYbEULykn7zxxxxAhwwoGVTZSdW4Tr                  
Privkey: 5JYigAyMiqTxYcxxxxrZpjTJ2F1fzQGWeTh9RyoHTxHzKoeF1L9
Pattern: 1scrybe                                            
Address: 1sCryBecTrLb8XxxxxfgNqFgi25owE4dr                  
Privkey: 5KEvjrgu2en6GpxxxxwGJA4YQJoGZgf5ANB4iEhSkwv9DjD4XxK
Pattern: 1scrybe                                            
Address: 1SCrYbERHo73aQxxxxEJpuUVyi5318n96                  
Privkey: 5Js2THPw56AHMfxxxxK42Khesuj4qz6DT8uQSQQf9Kiik7htw1e
Pattern: 1scrybe                                            
Address: 1SCRybEELZfmXoxxxx7kfGUYSeRsuCoyk                  
Privkey: 5KAu3gmBeTB1UTxxxxFwdG8mQK3oxZgiGpaQJjqPYv3N3N976NB



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

scrybe
Sr. Member
****
Offline Offline

Activity: 350



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


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: 355


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

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


firstbits:1MinerQ


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

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: 355


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

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



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

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: 938



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

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


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

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

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