Skip to content

Nonce and extraNonce: Expanding the Search Space

At its core, Bitcoin mining is a search problem. Your miner has a block header — a small chunk of data describing the block it’s trying to create — and it needs to find a version of that header whose SHA-256 hash falls below the current target. The data in the header is mostly fixed (it describes the transactions, references the previous block, etc.), so the miner needs some part of the header that it can change freely to produce different hash outputs.

That changeable part is called the nonce.

Think of it this way: you have a combination lock and you know the answer is somewhere between 0 and 4 billion. You try every number, one by one, twisting the dial each time. Each twist is a hash. The nonce is the number on the dial.

Before we dive deeper into the nonce, let’s look at what a Bitcoin block header contains. It’s exactly 80 bytes — tiny compared to the block itself — and has six fields:

FieldSizeDescription
Version4 bytesBlock version number (protocol rules)
Previous Block Hash32 bytesHash of the block before this one
Merkle Root32 bytesSummary hash of all transactions in the block
Timestamp4 bytesWhen the block was created (approximate)
Bits (Target)4 bytesCompact form of the current difficulty target
Nonce4 bytesThe value miners change to produce different hashes

The miner hashes this 80-byte header over and over. The only field specifically designed for the miner to modify is the nonce.

The nonce is a 32-bit unsigned integer, meaning it can hold any value from 0 to 4,294,967,295 (about 4.3 billion). When a miner gets a new block template from the pool, it typically starts the nonce at 0 and increments it by 1 for each hash attempt:

Hash(header with nonce = 0) -> some hash (too high, not valid)
Hash(header with nonce = 1) -> some hash (too high, not valid)
Hash(header with nonce = 2) -> some hash (too high, not valid)
...
Hash(header with nonce = 4,294,967,295) -> some hash (too high, not valid)

This process of systematically trying every nonce value is called grinding the nonce.

When your miner has gone through all 4.3 billion nonce values without finding a valid hash, it has exhausted the nonce space. Every possible version of this particular header has been tried. Now what?

Here’s the problem: 4.3 billion sounds like a lot, but modern ASIC miners blow through it in a fraction of a second.

Let’s do the math. An Antminer S21 runs at about 200 TH/s — that’s 200 trillion hashes per second. The nonce space is 4.3 billion (4.3 x 10^9). So:

Time to exhaust nonce = 4.3 x 10^9 / 200 x 10^12 = 0.0000215 seconds

That’s about 21.5 microseconds. Your miner chews through all 4.3 billion nonce values in less time than it takes you to blink. Then it’s stuck — it needs something else to change in the header to create new hash possibilities.

Back in the early days when people mined on CPUs at a few megahashes per second, 4.3 billion attempts was plenty. A CPU doing 10 MH/s would take about 7 minutes to exhaust the nonce — by which time a new block would likely have arrived, providing a fresh header to work on. But modern ASICs are roughly 20 million times faster. The nonce alone is laughably insufficient.

To understand the extraNonce, you need to know about one special transaction in every block: the coinbase transaction (not the company — the actual Bitcoin protocol term).

The coinbase transaction is the very first transaction in every block. It’s special because it has no input from a previous transaction — it’s where new bitcoins are created from thin air and awarded to the miner. The coinbase transaction is how miners receive the block reward (currently 3.125 BTC) plus all the transaction fees from the block.

Here’s the clever part: the coinbase transaction contains an arbitrary data field that miners can put anything into. Satoshi used this field to embed the famous newspaper headline in Bitcoin’s genesis block. But more importantly for mining, this field is where the extraNonce lives.

Remember the Merkle Root in the block header? It’s a hash that summarizes all transactions in the block. If you change even one transaction — or one byte within a transaction — the Merkle Root changes completely. And if the Merkle Root changes, the entire block header changes. And if the block header changes, you get a completely new set of 4.3 billion nonce values to try.

The chain goes like this:

Change extraNonce in coinbase transaction
-> Coinbase transaction hash changes
-> Merkle Root changes (because it includes the coinbase)
-> Block header changes
-> 4.3 billion new nonce values to explore

This is the trick. By modifying a tiny number in the coinbase transaction, the miner effectively resets the entire nonce search space.

In the Stratum mining protocol (the standard communication protocol between miners and pools), the extraNonce is split into two parts:

When your miner first connects to a pool, the pool assigns it a unique extraNonce1 value. This is essentially your miner’s ID within the pool. It ensures that different miners connected to the same pool are always working on different parts of the search space — they never duplicate each other’s work.

extraNonce1 is fixed for your session. You don’t change it; the pool does.

The extraNonce2 is the part your miner controls. It’s a counter that the miner increments each time it exhausts the 32-bit nonce space. The size of extraNonce2 varies (typically 4 to 8 bytes), and the pool tells your miner how large it is when it connects.

So the full mining loop looks like this:

  1. Set extraNonce2 = 0.
  2. Build the coinbase transaction with the pool’s extraNonce1 and your current extraNonce2.
  3. Compute the Merkle Root from all transactions (including the new coinbase).
  4. Assemble the block header.
  5. Grind through all 4.3 billion nonce values (0 to 4,294,967,295).
  6. No valid block found? Increment extraNonce2 by 1.
  7. Go back to step 2.

Each time extraNonce2 increments, you get a brand-new Merkle Root and therefore a completely new set of 4.3 billion nonce values. The search space becomes enormous.

Here’s a way to picture the whole system:

Imagine you’re searching for a specific sentence across a vast library. Each book represents a unique extraNonce2 value. Each page within a book represents a nonce value. The sentence you’re looking for (a hash below the target) could be on any page of any book.

  • Nonce = the page number. You start at page 1 and flip through every page in the book (0 to ~4.3 billion).
  • extraNonce2 = the book volume number. When you’ve checked every page in Book 1, you move to Book 2 (increment extraNonce2), which has a completely different set of pages to search.
  • extraNonce1 = the shelf assignment. The pool says “You search the books on Shelf 47; the miner next to you searches Shelf 48.” This prevents overlap.

Your miner never runs out of pages to search because there are effectively unlimited books (extraNonce2 values) on its assigned shelf (extraNonce1).

Let’s put this into perspective with a real-world timeline for a 200 TH/s ASIC:

StepTime
Exhaust full nonce range (4.3B hashes)~21.5 microseconds
Increment extraNonce2, rebuild Merkle RootA few microseconds
Start new nonce sweepImmediate

So roughly every 25 microseconds, the miner has:

  • Tried all 4.3 billion nonce values
  • Incremented extraNonce2
  • Rebuilt the coinbase and Merkle Root
  • Started the next sweep

In one second, a 200 TH/s miner goes through approximately 46,000 complete nonce sweeps, each with a different extraNonce2 value. That’s how it maintains 200 trillion hashes per second even though the nonce only allows 4.3 billion per sweep.

Understanding the nonce/extraNonce system helps explain several things you’ll encounter in practice:

Pools use extraNonce1 to partition work. If two miners had the same extraNonce1 and happened to use the same extraNonce2 at the same time, they’d be hashing identical headers — a complete waste. The unique extraNonce1 per miner prevents this.

When you look at Stratum protocol logs (useful for debugging), you’ll see:

  • mining.subscribe — the pool responds with your extraNonce1 and the size of extraNonce2.
  • mining.notify — a new job arrives with transaction data. Your miner combines this with its extraNonce values to build the block header.

Modern ASICs also use a technique called version rolling (or overt AsicBoost), where they tweak certain bits in the version field of the block header. This provides yet another dimension to search, on top of the nonce and extraNonce. Think of it as adding a third axis to the search space — now you’re not just flipping pages in books on a shelf; you’re also checking alternate editions of each book.

  • The nonce is a 32-bit field in the block header that miners change to produce different hashes. It allows ~4.3 billion attempts.
  • Modern ASICs exhaust the nonce space in microseconds, so 4.3 billion tries is nowhere near enough.
  • The coinbase transaction is the first transaction in a block; it contains arbitrary data including the extraNonce.
  • extraNonce1 is assigned by the pool (your unique ID). extraNonce2 is iterated by the miner.
  • Changing the extraNonce changes the coinbase transaction, which changes the Merkle Root, which changes the entire block header — creating a fresh set of 4.3 billion nonce values to try.
  • Think of it as: nonce = page number, extraNonce2 = book volume, extraNonce1 = shelf assignment.
  • Version rolling adds another dimension to the search, further expanding the space.

Next: Block Reward and Halving — where the BTC that miners compete for actually comes from, and why the reward keeps getting cut in half.