The Bitcoin Block Header Explained: Six Fields Your Miner Actually Hashes

The Bitcoin Block Header Explained: Six Fields Your Miner Actually Hashes

A Bitcoin block can hold thousands of transactions, but your Bitaxe never hashes any of them directly. It hashes one tiny summary over and over: the block header. Every share you have ever submitted and every block anyone has ever found came down to the same 80 bytes, arranged in the same six fields. Once you know what those fields are and who fills each one in, terms like "new job", "merkle root" and "nonce" in your AxeOS logs start to make a lot more sense.

The Bitcoin block header is an 80-byte summary of a block, and it is the only thing hashed for proof of work. It has six fields: version, previous block hash, merkle root, timestamp, nBits (the compact encoding of the target) and a 32-bit nonce. Bitcoin runs the header through double SHA-256; if the result is at or below the target, the block is valid. On a pool, the job tells your miner most of the header; your miner rolls the nonce, and when that runs out it changes the extranonce in the coinbase, which changes the merkle root. On Bitmern Solo, keep BTC easy-start host btc.bitmernsolo.com with port :3132, username WALLET.worker, password x. Current Effort is not a find guarantee.

This is the "what exactly gets hashed" lane. For why a low hash matters at all, start with proof of work explained. For how the merkle root is built from transactions, read block templates and the merkle root explained. For the search loop itself, read what is a nonce.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Nothing in this post is financial advice, and nothing here promises a find.

The one-sentence version

The block header is a block's ID card: small enough to hash quickly, but it fingerprints everything that matters about the block.

Why only the header is hashed

A full block can be large. Hashing the whole thing for every single attempt would be slow and pointless, because most of it never changes between attempts. Bitcoin's design solves this neatly:

• All transactions are summarized into a single value, the merkle root.
• The merkle root goes into the header.
• The header also carries a link to the previous block and the current target.

So the header commits to the whole block without containing it. Change any transaction and the merkle root changes, which changes the header, which changes the hash. Your miner gets to work on a fixed-size, 80-byte input, and the security still covers everything.

The six fields

Here they are in the order they sit inside the header.

# Field Size Who sets it (on a pool) 1 Version 4 bytes Pool, with some bits the miner may roll 2 Previous block hash 32 bytes Pool (from the current chain tip) 3 Merkle root 32 bytes Miner rebuilds it from the job + its extranonce 4 Timestamp (time) 4 bytes Pool suggests it; miner may adjust within rules 5 nBits 4 bytes Pool (from the network's current target) 6 Nonce 4 bytes (32-bit) Miner — this is the main dial it spins

Four plus thirty-two plus thirty-two plus four plus four plus four: 80 bytes. That is the whole thing.

1. Version

The version field signals which set of rules the block follows and can carry signals for proposed upgrades. For a home miner, the interesting part is that many modern ASIC firmwares negotiate version rolling with the pool: the miner is allowed to change certain bits of this field to get extra search space without asking for a new job. You do not configure this by hand; the firmware and pool agree on it.

2. Previous block hash

This is the hash of the block your block builds on — the current tip of the chain. It is what chains blocks together. It is also why a new block on the network instantly makes your current work stale: if someone else found the next block, your header still points at the old tip, so even a perfect hash would build on a block that is no longer the latest. When the pool sees a new tip, it sends a fresh job with the new previous hash. Read orphan and stale blocks explained for what happens when two blocks race.

3. Merkle root

A single hash that summarizes every transaction in the block, including the coinbase transaction that pays the finder. The pool does not send your miner every transaction; it sends the coinbase in two parts plus a merkle branch — just enough hashes for the miner to rebuild the root itself. Read block templates and the merkle root explained and the coinbase transaction explained.

In solo mining this matters directly: the coinbase in your job is the one that pays the wallet in your WALLET.worker. That payout is locked into the merkle root, which is locked into the header you are hashing.

4. Timestamp

Roughly when the block was made, in seconds. It does not have to be perfectly precise. Nodes only accept it if it is later than the median of recent blocks and not too far into the future. Within those limits the timestamp can move a little, which is another small source of search space. A miner with a badly wrong clock can still have trouble — see NTP clock drift.

5. nBits

The network target, stored in a compact form. A full target is a 256-bit number; nBits squeezes it into 4 bytes using a short exponent-and-mantissa encoding. Every node can expand nBits back into the full target and check whether a block's hash is low enough.

nBits only changes when difficulty retargets. You do not set it, and neither does the pool in any meaningful sense — it comes from the network's rules. Read difficulty adjustment explained.

Note that nBits is the network target. The pool's easier share bar is separate and is sent by Stratum, not stored in the header — see share difficulty explained.

6. Nonce

A 32-bit number the miner is free to change. It exists purely to give the miner something to spin. Your Bitaxe sets a nonce, hashes the header, checks the result, bumps the nonce, and repeats. Read what is a nonce.

A 32-bit field only holds so many values, and a fast ASIC can run through all of them very quickly. When it does, the miner needs a different header to keep going — which is where the extranonce comes in.

The extranonce: search space outside the header

The extranonce is not one of the six fields. It lives inside the coinbase transaction. But it changes the header indirectly:

1. The miner changes extranonce2 in the coinbase.
2. The coinbase hash changes.
3. The merkle root changes.
4. The header changes, so the nonce range can be searched again from scratch.

The pool also gives each connection its own extranonce1, so two miners on the same pool never hash identical headers. Read the Stratum protocol explained for where these values come from.

Who fills in what, step by step

When your Bitaxe receives a job (mining.notify), it gets the previous hash, the version, nBits, the time, the two coinbase halves and the merkle branch. Then:

1. It inserts extranonce1 and its own extranonce2 between the coinbase halves.
2. It hashes the coinbase and walks up the merkle branch to get the merkle root.
3. It assembles the 80-byte header.
4. It spins the nonce (and, where agreed, rolls version bits).
5. Each hash that beats the share difficulty is sent back as a share (mining.submit).
6. When the search space is used up, it bumps extranonce2 and goes back to step 2.

From the submitted values, the pool rebuilds the exact same header and checks the hash itself. If that hash is also at or below the target encoded in nBits, it is a block.

Why a new job changes the header mid-search

Two common reasons:

• A new block appeared on the network. The previous block hash changes. Old work is now building on a stale tip, so the pool sends a job with the clean-jobs flag and the miner drops everything older.
• The block template was refreshed. New transactions arrived, so the merkle root changes. The miner switches to the newer job.

Either way, the header your miner was hashing is no longer the one the pool wants. That is normal. Shares submitted for a replaced job may come back stale — see stale shares fix.

A header, laid out (EXAMPLE values only)

EXAMPLE ONLY — placeholder values, not a real block
version        : VERSION            (4 bytes)
prev_block     : PREVHASH...        (32 bytes)
merkle_root    : MERKLEROOT...      (32 bytes)
time           : NTIME              (4 bytes)
nbits          : NBITS              (4 bytes)
nonce          : NONCE              (4 bytes)
---------------------------------------------
total          : 80 bytes  -> double SHA-256 -> compare with target

Inside the real header these values are packed as raw bytes, not text, but the order and sizes are exactly as shown.

Ordered "header health" checklist

1. Confirm the stratum fields

Symptom: You want the coinbase in your header to pay the right wallet.

Fix: In AxeOS, check the stratum settings. Host:

btc.bitmernsolo.com

Port:

3132

Username:

WALLET.worker

Password:

x

Easy-start for BTC on a Bitaxe is :3132. The wallet in the username is the one written into the coinbase for a find. If it is wrong or malformed, see invalid wallet rejects.

2. Check jobs are arriving

Symptom: You want to know your miner is getting fresh headers to work on.

Fix: Your AxeOS logs should show new jobs arriving regularly. Read the AxeOS logs guide.

3. Check shares are accepted

Symptom: You want proof the headers your miner hashes match what the pool expects.

Fix: Open the matching coin tab on Bitmern Solo and look for fresh accepted shares under your worker. An accepted share means the pool rebuilt your header and got the same hash.

4. Keep stale shares low

Symptom: Some shares come back stale.

Fix: Stale shares usually mean a slow or unstable connection, so the miner finishes work on a header the pool already replaced. See stale shares fix.

5. Read Current Effort correctly

Symptom: Every header is healthy and effort is high, so a find feels due.

Fix: Each header hash is an independent draw. Current Effort is not a find guarantee — read Current Effort explained.

What this post will not invent

• No current difficulty, target, or nBits values
• No hashrate claims for any chip or Bitaxe model
• No claims about Bitmern Solo's internal job or template timing
• No price, profitability, or ROI figures — no financial advice

Common block header misunderstandings

1. "The miner hashes the whole block." It hashes only the 80-byte header, many times over.
2. "The nonce is the only thing that changes." The nonce changes most often, but the extranonce (through the merkle root), the timestamp and version bits can change too.
3. "nBits is the share difficulty." nBits is the network target. Share difficulty is a separate, easier bar set by the pool.
4. "The pool could swap in its own wallet after I find a block." The payout is in the coinbase, which is committed in the merkle root of the header you hashed. Change it and the hash changes.
5. "A new job means something went wrong." New jobs are normal — new blocks and new transactions both trigger them.
6. "High Current Effort means a block is coming." It does not. Current Effort is not a find guarantee.

Soft next step

Open AxeOS and confirm the four stratum fields above, with the wallet you want paid in WALLET.worker. Then open the matching coin tab on Bitmern Solo and watch accepted shares arrive — each one is an 80-byte header your Bitaxe built, hashed and proved. Keep BTC easy-start btc.bitmernsolo.com with port :3132 and password x.

Start mining

Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.

FAQ

What is in a Bitcoin block header?

Six fields in 80 bytes: version, previous block hash, merkle root, timestamp, nBits (the compact target) and a 32-bit nonce.

Why is only the block header hashed?

The merkle root inside the header commits to every transaction, so hashing the small header is enough to secure the whole block.

What is nBits?

The compact 4-byte encoding of the network target. Nodes expand it to the full target to check whether a block's hash is low enough.

What happens when the nonce runs out?

The miner changes the extranonce in the coinbase, which changes the merkle root and gives it a fresh header to search.

What does Bitmern Solo charge?

A flat 1% fee on finds only — you keep 99%.

Does Current Effort mean I am about to find a block?

No. Current Effort is an ops / attribution signal — not a find guarantee. See Current Effort explained.