How Does an ASIC Mine Bitcoin: The Mechanism

Behind the steady whir of an Antminer or Whatsminer is a tight computational loop that has not changed in its essentials since 2009: take a candidate Bitcoin block, plug in a number, hash it, check the result, repeat. The chips do this hundreds of trillions of times per second. So how does an ASIC mine Bitcoin in practical terms? This guide walks through the mining loop end to end — what comes in from the pool, what the chips do with it, what gets reported back, and what makes a winning block versus an ordinary share. The mechanism is simpler than its scale suggests.

The short answer: the chip tries trillions of nonces against a block template

An ASIC mining Bitcoin runs a continuous loop. The pool sends down a block template — a candidate block with a fully specified header except for the nonce field. The miner’s chips iterate through nonce values, hash the block header (specifically SHA-256 of the header, applied twice), and check whether the resulting hash is numerically smaller than the current target. Most of the time it is not. Occasionally it is. When it is smaller than the pool’s share target, the miner sends a share back. When it is smaller than the full network target, that share is also a winning block.

This loop is the entire mining workload. Everything else — the firmware, the web UI, the cooling, the power supply — exists to keep the loop running as fast and as efficiently as possible. The deeper algorithm-level mechanics are covered in the explainer on SHA-256 in Bitcoin, and the parent Bitcoin mining hub covers the broader context.

What an ASIC receives from the pool

Mining starts with a block template. The pool builds one by selecting transactions from the mempool, ordering them, computing a Merkle root, and assembling an 80-byte block header containing six fields: protocol version, previous block hash, Merkle root, timestamp, the current difficulty target (compactly encoded in the “bits” field), and the nonce. The nonce is the only field the miner is supposed to vary.

The template is delivered via the Stratum protocol. Modern miners typically open a TCP connection to stratum+tcp://pool.example.com:3333, authenticate with a worker name, and receive a stream of job messages. Each job message contains the header data and the share target the pool expects. Stratum V2, adopted by Braiins Pool and some Foundry traffic, expands this with end-to-end encryption and the option for miners to construct their own block templates. The deeper unpack of templates is in the piece on block templates explained.

The nonce search loop

With a template in hand, the chips begin nonce iteration. The nonce field is a 32-bit number, giving roughly 4.3 billion possible values per iteration. The chip starts at 0 (or some assigned offset), writes that value into the nonce field, computes SHA-256(SHA-256(header)), and checks the result. The check is a numerical comparison: is the 256-bit hash less than the target?

For a modern Antminer S21 XP running at roughly 270 TH/s, the chips exhaust the entire 32-bit nonce space in about 16 microseconds. That is too fast for one nonce range alone. So the miner also varies other fields — specifically the extranonce, a portion of the coinbase transaction that the pool tells the miner it may modify, and the block timestamp within a small window — to extend the search space. The combination of nonce, extranonce, and timestamp gives a practically unlimited search range. The conceptual depth around the nonce specifically lives in the Bitcoin nonce explainer.

What “finding a share” actually means

The pool sets a share target much easier than the full network target — typically thousands or millions of times easier. When a miner’s chip produces a hash that satisfies the share target (but not necessarily the network target), the miner submits that hash plus its nonce back to the pool over Stratum. The pool verifies the share — it can recompute the hash from the same template and confirm — and credits the miner’s account.

Shares are how pools measure each miner’s contribution. The pool keeps a running count of every worker’s accepted shares and uses that count to allocate block rewards when one is found. The deeper explainer on how shares get paid out across different schemes lives in the piece on PPS vs FPPS vs PPLNS. Shares that satisfy the network target too are also winning blocks; the pool broadcasts them to the network immediately.

What makes a winning block

Bitcoin’s network target is set by current difficulty. As of mid-2026 the target is small enough that any single hash has roughly a one-in-10^23 chance of meeting it. To put that in perspective, a 270 TH/s ASIC would on average need to run for about a decade to find one winning block alone. Pools aggregate millions of miners’ hashrate, so the pool collectively finds a block every few minutes on average.

When a hash does satisfy the full network target, three things happen in sequence. The miner submits the share to the pool. The pool validates it. The pool broadcasts the full block — header plus all transactions — to the Bitcoin peer-to-peer network. Other nodes verify the block (checking proof of work, transaction validity, timestamps) and add it to their chain. The miner that found it does not get paid directly by the network; the pool collects the 3.125 BTC subsidy plus transaction fees, then distributes proportional payouts to all contributing miners.

Why two SHA-256 passes

Bitcoin hashes the block header through SHA-256 twice — known as double-SHA-256 or SHA-256d. The reasoning, as best as can be reconstructed from Satoshi’s writings, was defense against length-extension attacks on plain SHA-256. The practical effect is that every hash attempt costs two SHA-256 operations. ASIC designs are heavily optimized around this: each chip contains thousands of small SHA-256 cores, and they are pipelined so that the output of the first SHA-256 immediately feeds the second.

The total compute behind one TH/s of Bitcoin mining is therefore 10^12 double-SHA-256 operations per second, or 2 × 10^12 individual SHA-256 operations. A 270 TH/s machine does 5.4 × 10^14 SHA-256 ops every second. That is far beyond what any general-purpose CPU or GPU can sustain at any reasonable power budget, which is why ASIC chips replaced GPUs entirely from 2013 onward.

The role of the controller and firmware

The chips do the hashing, but they do not do everything. Each ASIC miner contains a small ARM control board running embedded Linux. This controller handles the Stratum connection to the pool, distributes work to the hashboards, collects share submissions back from the chips, and exposes the web UI for operator configuration. It also runs the watchdog logic that monitors fans, chip temperatures, and PSU voltages.

Firmware quality varies by vendor. Stock Bitmain firmware is mature but conservative. Custom alternatives like BraiinsOS, LuxOS, and Vnish add per-chip tuning, autotuning, and Stratum V2 support. The trade-offs of running stock versus custom firmware are covered in the piece on custom ASIC firmware risks. The controller also speaks Stratum extensions for fail-over pool configuration and rejected-share reporting.

Why some shares are rejected (and what stale means)

Not every submitted share gets accepted. The pool rejects shares for several reasons. A share that does not actually satisfy the share target (a calculation error or, rarely, a buggy chip) is rejected as invalid. A share submitted after the pool has already found a block on the current template is rejected as “stale” because that template is no longer current. Network latency, pool switching, and the natural time gap between block discovery and template propagation all contribute to stale shares.

A small percentage of stale shares is normal — typically under 1% for a well-connected miner. Higher rates point to network problems or to chip-level issues like a bad hashboard producing invalid output. The dedicated piece on stale shares walks through the diagnosis. Configuring a low-latency pool and a stable internet connection are the two main mitigations.

What happens after a block is found

A winning block enters the Bitcoin network’s gossip protocol and propagates to all reachable nodes within seconds. Each node validates the block independently — checking the proof-of-work, verifying every transaction’s signatures, confirming no double-spends — and either accepts it or rejects it. Honest nodes accept valid blocks. The pool that found the block earns the 3.125 BTC subsidy plus all transaction fees from the block’s transactions. As of mid-2026 a typical block carries 0.1 to 0.5 BTC in fees, depending on mempool congestion.

Pool payouts to individual miners then run on whatever schedule and method the pool uses. Foundry, AntPool, F2Pool, ViaBTC, and others each have their own payout cadence — usually daily, sometimes weekly, always above a minimum threshold. Connecting all of this back to operator economics is the work of the 2026 profitability analysis.

References

• How Bitcoin mining works technical guide — Braiins
• How Bitcoin mining actually works — Bitcoin Magazine
• Antminer S21 XP specification page — Bitmain
• Live Bitcoin block and mempool data — mempool.space

For miners running the loop on current-generation hardware, the Coin Web Mining catalog stocks new and refurbished Bitcoin ASICs from Bitmain, MicroBT, and Canaan.