nBits and Target: Understanding Difficulty Encoding

A block is accepted if the double SHA-256 of its header is strictly smaller than a target. That target is a large integer which does not travel in long form inside the header: it is packed there into the nBits field. The difficulty an explorer displays is yet another way of naming the same threshold.

The target

Picture the space of all possible hashes, 256 bits wide. The target is a threshold in that space, and a hash that passes is a number below it. The smaller the target, the rarer valid hashes become. The protocol holds a block pace near ten minutes by moving that threshold as collective work speeds up or slows down.

You do not choose the network target: nodes derive it from the chain. The pool gives you a second one, the share target, deliberately looser, which it uses to count your work between blocks.

nBits, the same target in compact form

nBits is a compact encoding of the target, four bytes in the header. The protocol describes it as an exponent and a mantissa, from which the large integer compared against the hash is reconstructed.

That compact format exists because the header has to stay small and fixed in size. Copying a 32-byte target into every block would add nothing nodes cannot rebuild. nBits is therefore the carried contract, and the expanded target is what the verifier compares.

Two points matter in practice:

• Not every four-byte pattern forms a valid target. Nodes apply bounds and format rules, and a fabricated nBits does not produce an acceptable block.
• nBits is identical for everyone during a difficulty period. Firmware does not tune it, it copies it from the job it receives.

The bit-level detail of the encoding lives in the protocol and in node code. If you write a parser, start from those sources rather than from an article.

Difficulty, the target inverted

Difficulty is a ratio between the current target and a historical reference target, the protocol maximum tied to difficulty 1. The higher the ratio, the smaller the current target. Difficulty and target therefore say the same thing in opposite directions.

Interfaces mix these words freely. An operator has to keep three objects apart:

• the network target, or nBits: the next block's puzzle;
• network difficulty: that same puzzle in a more readable unit;
• share difficulty: the pool's meter, deliberately lower.

Confusing them produces bad diagnoses. A common example: believing a network retarget should change your share rate at constant pool difficulty. Your machine hashes exactly as much; what moves is the value of that work against the global puzzle.

The retarget happens on its own

Every 2016 blocks, the network compares elapsed time to the intended span, 2016 times ten minutes, and moves the target, hence nBits, hence difficulty. The step is capped from one retarget to the next, and between them nBits stays constant.

You never have to compute nBits by hand to mine. If a job shows an nBits that does not match the chain tip your node sees, though, the problem is the template, not your nonce.

Three useful reflexes

• Read nBits as the identity of the current difficulty period, which lets you date a job at a glance.
• When an explorer, a pool, and firmware show three different difficulties, first check which object each is naming. Comparison only means something at identical units.
• Never drop an archive target into a forecast spreadsheet: it belongs to a difficulty period that has passed, and any projection built on it understates real difficulty.