Bitcoin Forum

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.

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.

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

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

The fact that we can use uint4 (VECTORS4) to increase efficiency should indicate that it's capable of 64-bit processing.

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.

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.

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

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:


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.