Bitcoin Forum
December 11, 2016, 04:22:40 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Proof of concept kernel coming up soon!  (Read 1611 times)
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 04:09:57 AM
 #1

Hey all!  I'm sort of new to the OpenCL coding scene and I decided I wanted to try my hand at coding a kernel for Phoenix Miner.  So, I'm deciding to attempt to use 128-bit (and possibly 256-bit) vectors to compute SHA-512 hashes and then truncate them to SHA-256 for enhanced speed.  ^_^
If anyone wants to help, let me know!  I could us it.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
1481430160
Hero Member
*
Offline Offline

Posts: 1481430160

View Profile Personal Message (Offline)

Ignore
1481430160
Reply with quote  #2

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

Posts: 1481430160

View Profile Personal Message (Offline)

Ignore
1481430160
Reply with quote  #2

1481430160
Report to moderator
1481430160
Hero Member
*
Offline Offline

Posts: 1481430160

View Profile Personal Message (Offline)

Ignore
1481430160
Reply with quote  #2

1481430160
Report to moderator
1481430160
Hero Member
*
Offline Offline

Posts: 1481430160

View Profile Personal Message (Offline)

Ignore
1481430160
Reply with quote  #2

1481430160
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 02, 2012, 04:16:39 AM
 #2

I don't think that is going to work.  SHA-512 uses 64bit words and SHA-256 uses 32bit.

You can't just truncate SHA-512 hashes to get SHA-256 ones.
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 04:26:44 AM
 #3

And that's why I call it a proof of concept.   Tongue

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 02, 2012, 04:40:02 AM
 #4

What hardware supports the larger vectors natively?  I toyed around with the kernel when I got my 5970's... if I recall correctly, the hardware registers themselves were 32 bits so it wouldn't matter if you asked for a bigger data type, you would get no gain (and most likely a loss) because it would simply split the bigger operations into the smaller registers.

I did some Googling on the newer hardware, and was led to believe that the ALU's in newer graphics cards support 64 bit operations.  Who knows, maybe it's possible to jam two SHA256 operations in a pipeline using the same set of registers without wasting too many cycles cleaning up little messes (like doing two 32-bit adds together in a 64-bit register, but somehow making sure that overflow from the bottom 32 bits doesn't carry into the top 32 bits etc.)

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 05:06:17 AM
 #5

The code itself should support uint8 or even uint16 if entered as far as I see in the specs.  This is more-so in the planning stages and I'm looking for some assistance in it.  Here's the reference for the initial inspiration:  http://eprint.iacr.org/2010/548.pdf
Now, if this holds true and the hardware will compute uint8 efficiently, we may have ourselves a more efficient VECTORS8 kernel that can be modified if anyone should ever need a SHA-512 for whatever reason.
Edit:  The problem I've seen with long long is that it's a reserved function.  But I did see that uint8 and uint16 were listed in the reference card and elsewhere.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 05:11:16 AM
 #6

What hardware supports the larger vectors natively?  I toyed around with the kernel when I got my 5970's... if I recall correctly, the hardware registers themselves were 32 bits so it wouldn't matter if you asked for a bigger data type, you would get no gain (and most likely a loss) because it would simply split the bigger operations into the smaller registers.

I did some Googling on the newer hardware, and was led to believe that the ALU's in newer graphics cards support 64 bit operations.  Who knows, maybe it's possible to jam two SHA256 operations in a pipeline using the same set of registers without wasting too many cycles cleaning up little messes (like doing two 32-bit adds together in a 64-bit register, but somehow making sure that overflow from the bottom 32 bits doesn't carry into the top 32 bits etc.)
The fact that we can use uint4 (VECTORS4) to increase efficiency should indicate that it's capable of 64-bit processing.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
February 02, 2012, 05:29:02 AM
 #7

The paper suggests using truncated SHA512 as an alternate hashing algorithm for SHA256, when using a 64 bit architecture, a 256 bit hash is still desired, and a more efficient routine is wanted. They run SHA512, and only output 1/2 of the 512 bit hash. It doesn't say anywhere that the hash output of their SHA512->256 is going to be the same as SHA256.

Hashing algorithms are used for data integrity and password storage, so on a closed system like storing password hashes, it doesn't matter if the hash is different from another algorithm, as long as it is robust and already subject to lots of peer review. With Bitcoin, you still need a SHA256(SHA256()) hash to come out of the thing.

d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 07:46:06 AM
 #8

So, SHA-512/256 isn't the same as SHA-256?
That's a confusing and embarrassing letdown.

Oh well, at least we can play around with larger vectors in the phatk2 kernel for now.

Now how to fix that nonce problem...

I thought that the biggest difference was in the initial values for the algorithm.  If anyone knows for certain if these two algorithms are completely different as shown in the documentation above, I would appreciate it.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 07:50:40 AM
 #9

Well, okay.  I'm feeling like an idiot now.  Someone care to move me back to the noob section?   Tongue

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 02, 2012, 01:18:56 PM
 #10

I thought that the biggest difference was in the initial values for the algorithm.  If anyone knows for certain if these two algorithms are completely different as shown in the documentation above, I would appreciate it.

Yes the two algorithms are completely different.

Each "word" in SHA-256 is a 32 bit number.
Each "word" in SHA-512 is a 64 bit number.

SHA-256 has 64 rounds.
SHA-512 has 80 rounds.

The block size  (input "chunk") of SHA-256 is 512 bits.
The block size  (input "chunk") of SHA-512 is 1024 bits.

Both use the same basic algorithms (all SHA-2 hashes do) but there is no conversion from the output of to the output of the other.

For example the null hash (hash empty string) is:

Code:
SHA256("")
0x e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA512("")
0x cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e

The reason the articles suggested using a chopped down version of SHA-512 is because for modern CPU the 64 bit operations are faster. So if someone wanted faster performance but only wanted 256 bit hashes (for database compatibility reasons) an ALTERNATIVE to SHA-256 would be a chopped version of SHA-512.


d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
February 02, 2012, 06:36:45 PM
 #11

I thought that the biggest difference was in the initial values for the algorithm.  If anyone knows for certain if these two algorithms are completely different as shown in the documentation above, I would appreciate it.

Yes the two algorithms are completely different.

Each "word" in SHA-256 is a 32 bit number.
Each "word" in SHA-512 is a 64 bit number.

SHA-256 has 64 rounds.
SHA-512 has 80 rounds.

The block size  (input "chunk") of SHA-256 is 512 bits.
The block size  (input "chunk") of SHA-512 is 1024 bits.

Both use the same basic algorithms (all SHA-2 hashes do) but there is no conversion from the output of to the output of the other.

For example the null hash (hash empty string) is:

Code:
SHA256("")
0x e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA512("")
0x cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e

The reason the articles suggested using a chopped down version of SHA-512 is because for modern CPU the 64 bit operations are faster. So if someone wanted faster performance but only wanted 256 bit hashes (for database compatibility reasons) an ALTERNATIVE to SHA-256 would be a chopped version of SHA-512.



Yeah, I thought it was a matter of requiring different constants and changing a few rounds.  Sadly, not the case.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
Pages: [1]
  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!