# Bitcoin mining: how is a block header of 80 bytes processed in SHA-256? Isn't it too big?

The whole process of bitcoin mining was making sense to me until a moment of madness an hour ago, if there are 80 bytes of data to be processed in SHA-256, that's 640 bits of data to be processed in SHA-256.

In this 80 bytes we have: 4 bytes (version), previous block hash (32 bytes), merkle root (32 bytes), time (4 bytes), bits (4 bytes), nonce (4 bytes).

I thought SHA-256 accepted 512 bits of data, so that's 64 bytes of data. And on top of that, I need to add the length of the data to be processed in the last 64 bits of this 512 bits input but 64 bytes is well over the limit.

Then I saw that I would have to create basically two 512 bit input "blocks". The first block holds 512 out of the 640 input, and the second block holds the remaining 128 data bits, one bit to signal the end of the data and then padded up with 0s until the last 64 bits to indicate the length.

Can someone confirm if this is correct, and explain more on how this is done? I'm trying to implement my own SHA-256 module in VHDL since I couldn't find any but having more than a 256 input really makes it more confusing.

What am I missing here? Can someone help clear it up for me?

The SHA-256 compression function takes a 256-bit chaining value $$h$$ and a 512-bit message block $$m$$ and returns a 256-bit chaining value $$f(h, m)$$.
The SHA-256 hash function takes a padded message $$m$$ broken into an integral number of 512-bit message blocks $$m = m_1 \mathbin\| m_2 \mathbin\| \cdots \mathbin\| m_\ell$$, up to $$\ell \leq 2^{55} + 1$$ blocks long (the unpadded message length in bits, encoded into the last block, is 64 bits, allowing up to $$\lceil(2^{64} - 1)/512\rceil = 2^{55}$$ message blocks plus one more for the padded length), and iterates the compression function using a standard initialization vector $$\mathit{iv}$$ as the initial chaining value: $$H(m) = f(\cdots f(f(\mathit{iv}, m_1), m_2)\cdots, m_\ell).$$
If you are considering messages of the form $$m_1 \mathbin\| m_2^i$$ where you vary $$m_2^i$$ for the $$i^{\mathit{th}}$$ iteration, then of course you can precompute $$h_1 = f(\mathit{iv}, m_1)$$ and then use only a single evaluation of the SHA-256 compression function to compute $$H(m_1 \mathbin\| m_2^i)$$ by $$f(h_1, m_2^i)$$.
• $2^{64}-1$ bits ~ $2^{55}$ blocks. For bitcoin note the header nonce field (nominally) incremented for the inner loop is in the second SHA256 block, so miners typically precompute the midstate for block 1 of the inner hash, then iterate doing block 2 of the inner hash and block 1-and-only of the outer hash. – dave_thompson_085 Apr 11 '19 at 3:06