Detailed guide for implementing SHA256

SHA256 is a big part of how Bitcoin operates, popping up everywhere from address creation to signing transactions and mining blocks. I want to clear up how SHA256 works behind the scenes, so you can see why it’s so tough to crack. This thread is aimed at anyone looking to build their own SHA256 functionality on a CPU, GPU, FPGA, or whatever. What can you use it for? - Brainflayer - Vanitysearch - Getting back lost private keys - Mining (where SHA256 is used twice) - Any situation where you need SHA256 done super fast Check out this interactive demo (not mine): https://sha256algorithm.com/ Just a heads up it’s not meant for secure applications. It’s all about speed. SHA256 variables In SHA256, all variables are 32 bits in length except for the message itself. Even the arrays consist of 32-bit elements. We have 8 state variables. Normally, they would be in an array, but you could think of them as a, b, c, d, e, f, g, and h. Each of these is 32 bits long. They start out set to the first 32 bits of the square roots of the first 8 prime numbers. When the SHA256 process wraps up, all these variables are put together to make the final checksum. How’s that done? Let’s look at the first prime: 2. The initial digits of the square root of 2 are 1.4142135... but we’re not looking for those decimal places. We need to convert this into binary first. Als

I had a quick  comparison with the  NIST standard and noticed the discrepancy relevant to those constants. NIST refers to eighty of them. Does it make any sense to limit their number in your scheme of calculation or I  have missed something?

sha224 and sha256 only use the first 64 of those constants. The other SHA2 functions use all 80 of them: https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions Interestingly, SHA1 also uses 80 rounds.

There is a better way to see those values. Just square them, and see, how their 64-bit representation looks like. SHA-1 k-value constants squared: Note that in case of SHA-1, we have sqrt(2), sqrt(3), sqrt(5) and sqrt(10). We don't use sqrt(7) here, which would mean using 0xa953fd4e instead of 0xca62c1d6: SHA-256 initialization vector squared: Of course, here we have bigger values than 64-bit, because instead of handling only the fractional part, the whole number is handled, so when we have 1.4142135, we square 14142135, instead of squaring 4142135. Edit: By the way, RIPEMD-160 uses exactly sqrt(7) instead of sqrt(10): Another interesting fact is potential expansion of SHA-1 from 160-bit into 256-bit hash function, to preserve the first 160 bits "as they are". If anyone needs that kind of change, then this Initialization Vector can be used: And those values are also used elsewhere, for example here: https://www.rfc-editor.org/rfc/rfc7008

Yeah, agreed, as defined by NIST standard,  sha512/256 is sha512 truncated to 256 bits   and as such it uses 80 rounds with 80 constants, while sha256 has 64 rounds and relies on 64 constants. According to NIST, besides SHA1 the whole 80 rounds are also valid for SHA384 and truncated SHA512/224

Can you also do a short explanation on why Satoshi might have decided not to use a stronger algorithm? Some say, it would have been too slow or it would have bloated the Blockchain. (MD5 or SHA-1or SHA-2 or even SHA-512)

To be honest, I am not very sure why Satoshi chose to use SHA256, RIPEMD160, and even secp256k1. I do know that the two hashing algorithms are much stronger than MD5. SHA2 is obviously stronger than SHA1. MD5 and SHA1 have both been broken since he vanished so there's that. On the contrary, SHA256 is not slow to run, as newer hardware has opcodes that can run a SHA256 hash directly - x64 cpus have them, ASICs have them, the GPU implementation of SHA256 by JeanLucPons is quite fast, and so on.

https://en.wikipedia.org/wiki/MD5 https://en.wikipedia.org/wiki/SHA-1 However, Satoshi initially picked SHA-1, and repeated all steps, which were done in Hashcash. You can confirm that, if you download "BitCoin v0.01 ALPHA" version, and read for example "sha.h" file: This is also one of the earliest timestamps, which can confirm, that Satoshi started working on Bitcoin in 2007. Here, you can see 24th September 2007, but maybe some earlier date can be found elsewhere (or maybe not, because the hashcash version is very old, and the code at that time probably didn't contain much more than just hashing). This is what we have. See file "key.h" in the same 0.01 version: Satoshi used uncompressed public keys, which took 520 bits (expressed in code as 65 bytes). And he concluded, that they are too big to get a convenient address, and applied SHA-256 on that, and then put it through one more hash function, which is RIPEMD-160. SHA-256: because it is different than what Hashcash used, because it was considered strong at that time, and because it was available by default in secp256k1. RIPEMD-160: because he needed some shorter hash for addresses, 512-bit (x,y) coordinates were too big, 256-bit shortened addresses were still not small enough, and SHA-1 was too weak, and there were not that much 160-bit hash functions to choose from. secp256k1: because it was one of those four curves, considered by Satoshi, and because it was the most secure in that group. Picking for example secp160k1 could be also a good choice for short-term transactions, just like picking 160-bit addresses is good enough for that, but in the long term, the collision resistance is only at 2^80, and can be often bring down into 2^64, and then you enter a danger zone. So, to be safe, it is better to pick some 256-bit curve with 128-bit security. Note: at that time, pay-to-IP was the main use case, addresses were used later as a "feature", recommended to be used only if someone is not online, and everything started just from P2PK, called "direct payment" at that time. Also, those four curves are one of those, which have quite well-explained parameters (except of the Generator).