SHA-256: Bitcoin's Mining Algorithm

A Bitcoin ASIC does one thing: hash an 80-byte block header twice until the result falls under a target. Understanding that loop explains why the nonce keeps rolling, why a graphics card never catches up, and what to check when the pool cannot see your hashrate.

What the machine actually hashes

Useful Bitcoin mining work is a double SHA-256 (often written hash256) of an 80-byte block header. The header is not the full block. In the usual order it holds: version, previous block hash, Merkle root of the transactions, timestamp, the compact target field (nBits), and a 32-bit nonce.

The rest of the block, meaning the transaction list, is not re-hashed on every try. It is summarized once in the Merkle root. Change a transaction (or the extranonce in the coinbase) and that root changes, so the header changes, so the search space changes.

SHA-256 maps an input to 32 bytes. Double SHA-256 is SHA-256(SHA-256(header)). The network compares that digest to the current target: the hash must be numerically below the target. A smaller target means valid hashes are rarer.

No known shortcut computes the right nonce ahead of time. The machine tries them one by one.

Nonce and extranonce: why the sweep never stops

The header nonce is 32 bits, about four billion values. A modern ASIC burns that space in a fraction of a second. Then something else has to change.

In practice the pool sends a job over Stratum: version, prevhash, coinbase parts, Merkle branches, nBits, nTime. Firmware builds the header and rolls the nonce. When the space is exhausted, it increments an extranonce in the coinbase, rebuilds the Merkle root, and starts again. nTime can also move inside a narrow window.

So the machine is not aiming at a block every second. It sweeps a huge space and sends the pool any hash that meets the share target, which is far easier to hit than the network target. That share flow is what fills your dashboard.

Why the hash runs twice

Header proof-of-work uses two successive SHA-256 passes, not one. That is the protocol contract, and the ASIC is wired for that exact loop rather than for generic SHA-256 in the file-checksum sense.

The practical consequence: the hashrate on the sticker is a trial rate on this puzzle. A TH/s figure compares to the TH/s of another SHA-256 ASIC and to nothing else, least of all to the compute power of a general-purpose machine.

Why ASICs, not GPUs

SHA-256 is regular and not memory-hard. You can tile thousands of identical cores that do only that, with little SRAM and a lot of pipeline. An ASIC (application-specific integrated circuit) is that chip: it does not game, it does not render, it hashes.

A GPU stays general-purpose and loses on both counts, useful throughput and joules per terahash. In 2026, mining Bitcoin on anything other than a SHA-256 ASIC is a hobby or a demo.

What that changes when you buy:

• The hardware has to be Bitcoin / SHA-256 specific. An ASIC built for another algorithm family will not mine Bitcoin.
• The unit the pool cares about is TH/s, meaning attempts per second.
• The unit the bill cares about is J/TH (watts divided by TH/s). Two machines at the same TH/s do not cost the same to run.

There is nothing to hand-optimize inside SHA-256. The levers sit elsewhere: pick the machine, set a power mode, install stable firmware, then check that pool-reported hashrate matches local hashrate, minus share loss.

What an operator actually watches

A block-winning hash is rare. What you see every second is shares. An accepted share proves the machine produced a double SHA-256 under the pool difficulty; it says nothing about finding a block.

If local hashrate is high and the pool sees nothing, SHA-256 is not the problem. Check in this order: the job received, the network link, the worker name, then firmware hashing off the template.

Network difficulty retargets every 2016 blocks. Treat it as a number to re-read when you redo your return calculations, not a constant to copy. Your machine keeps hashing the same header shape with the same algorithm.