nBits

Bitcoin needs a 256 bit target in a header that cannot spare 32 bytes for it, so it stores a rounded version in four. The first byte is an exponent, the remaining three are a coefficient, and the target is the coefficient multiplied by 256 raised to the power of the exponent minus three. Every node recomputes the value it expects, so a header claiming an easier target than the rules allow is rejected outright.

How it works

nBits is read as one exponent byte followed by a three byte coefficient, and the two are combined into a full 256 bit number.

Take the value carried by the genesis block, 0x1d00ffff. The exponent is 0x1d, which is 29, and the coefficient is 0x00ffff, which is 65,535. The target is therefore 65,535 multiplied by 2 to the power of 208, a number written as eight hexadecimal zeros, then ffff, then zeros to fill 64 digits. That is the easiest target mainnet permits, and it is the definition of difficulty 1.

Two quirks catch people out. The first is precision. A coefficient of only 24 bits cannot express an arbitrary 256 bit number, so the encoded target is always a rounded one, and a round trip from target to nBits and back does not always return what you started with. The second is the sign bit. If the top bit of the coefficient is set, the value is treated as negative, so encoders shift the coefficient down a byte and raise the exponent to compensate. That is why the genesis value reads 0x1d00ffff rather than the more obvious 0x1cffff00, and why a leading zero byte inside the coefficient is normal rather than a bug.

In the serialized header the field sits at byte offset 72 and is written little endian, so those four bytes appear on disk and on the wire as ff ff 00 1d.

Where you see it

nBits travels under several different names, which is most of the confusion surrounding it.

Block explorers label it "bits" and print the hex value beside a friendlier difficulty figure. The Bitcoin Core RPC getblock returns it as "bits", and getblocktemplate hands it to mining software as the requirement a candidate header has to beat. In the source it is the nBits member of CBlockHeader, converted by arith_uint256::SetCompact and GetCompact. Mining pools rarely surface it at all: Stratum ships the same four bytes to machines inside a job notification, and the firmware never has to think about what they mean.

The field also changes on a schedule rather than continuously. It is fixed for a whole window of 2,016 blocks and only takes a new value at a retarget, so two blocks mined an hour apart carry an identical nBits field unless a retarget fell between them.

nBits vs target threshold

nBits is the encoding; the target threshold is the number it encodes. A node never compares a header hash against nBits directly. It expands the four bytes into a full 256 bit target first, then checks that the hash sits at or below that value. Treating nBits as the target itself is fine in conversation and wrong in code, because two nBits values a single unit apart decode to targets that differ by an enormous absolute amount.