How Bitcoin hashing works

Mining is a search for a block header whose SHA256d hash, read as a 256-bit number, comes out below a network-wide target. Hashes are unpredictable, so there is no shortcut. You change something in the header, hash it, and check. Whoever finds one first gets to extend the chain.

1. SHA256d, or hash twice

Bitcoin applies SHA-256 twice: the 80-byte header goes through SHA-256, and the resulting 32-byte digest goes through SHA-256 again. No salt, no key. Every block hash you have ever seen is the output of those two passes.

Input

80-byte header

→

Round 1

SHA-256

→ 32-byte digest

→

Round 2

SHA-256

of that digest

→

Block hash

32 bytes

2. The 80-byte block header

A Bitcoin block header is exactly 80 bytes. These six fields are all that gets hashed. The transactions themselves appear only through the merkle root.

Version

4 bytes · little-endian uint32

Signals which consensus rules the miner is ready to follow. Part of it is also rolled as extra search space.

Previous block hash

32 bytes · reverse of the order explorers print

Chains this block to the one before it. This single field is what makes the history a chain: rewrite an old block and every hash after it breaks.

Merkle root

32 bytes · reverse of the order explorers print

One hash standing in for every transaction in the block. Change any transaction, or the coinbase, and this value changes with it.

Timestamp

4 bytes · little-endian uint32

When the miner says the block was made, in Unix seconds. Nodes accept a range rather than an exact value, which leaves a little room to roll.

Bits

4 bytes · little-endian uint32

The target this block had to beat, packed into four bytes as an exponent and a coefficient.

Nonce

4 bytes · little-endian uint32

A counter with no meaning of its own. Its only job is to change the hash, and at 2^32 values it runs out almost immediately.

80 bytes → SHA-256 → SHA-256 → 32-byte block hash

3. What miners actually change

The nonce is a 32-bit field, so it offers only 2³² candidates, about 4.3 billion of them. A single modern ASIC at roughly 200 TH/s sweeps that entire range in about 20 microseconds. The nonce on its own stopped being enough more than a decade ago.

The search space actually comes from four places:

The nonce. 2³² tries, swept in microseconds. This is the innermost loop, not the real source of variety.
The coinbase transaction. Miners put an arbitrary "extranonce" in it. Changing the coinbase changes its hash, which changes the merkle root, which yields a completely fresh 80-byte header and another 2³² nonces to sweep. This is where the search space really comes from, and it is why pools hand out work as a coinbase template rather than a finished header.
The version field. Not all 32 bits of it carry meaning. Under the Stratum version-rolling extension (BIP 310) miners negotiate a mask, conventionally 0x1fffe000, and are free to vary the 16 bits it covers. That multiplies every other combination by another 65,536 headers without touching the coinbase. The bits outside the mask are left alone precisely because they are consensus signalling, so rolling must not collide with a deployment in progress. You may see this called overt AsicBoost.
The timestamp. It can be moved forward within the range nodes will accept, giving a few more headers per second of wall clock.

Every candidate header is an independent trial. There is no partial credit and no state carried between attempts, which is exactly why hash rate maps so directly onto the odds of winning a block.

4. Byte order trickery

SHA-256 emits 32 bytes in a fixed order, and that is the order Bitcoin serializes and compares them in, as a little-endian 256-bit integer. Explorers print the same bytes reversed, big-endian, which is the conventional way to write a number. Both strings below are the same hash and only the reading direction differs. That reversal is why block hashes look like they start with a run of zeros.

Explorer order (big-endian)

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

5. Target and difficulty

The target is not stored directly. The bits field holds a compact form: the high byte is an exponent, the low three bytes a coefficient.

target = coefficient × 2^(8 × (exponent − 3))

bits 0x1d00ffff gives exponent 0x1d = 29, coefficient 0x00ffff = 65535

target = 00000000ffff0000000000000000000000000000000000000000000000000000

That is the difficulty-1 target, the easiest the rules allow. A hash must be numerically below it, which means at least 32 leading zero bits, and takes roughly 4,295,032,833 attempts on average. Today's target is far lower, so far more attempts are needed. Difficulty is just the ratio between the difficulty-1 target and the current one.

Every 2016 blocks, about two weeks, nodes compare how long those blocks actually took against the intended two weeks and adjust the target to pull the average back toward one block every 10 minutes. The adjustment is capped at a factor of 4 in either direction per retarget. No authority sets it. Every node computes the same value from the same chain.