Target, bits & Difficulty

Proof of Work told us a valid block is one whose hash is below the target. This page zooms in on that one word: target. What is it, exactly? How is it stored in the block header in only four bytes? And what’s the difference between the target (a raw threshold) and difficulty (the number people actually quote)? Getting these straight is the difference between reciting “leading zeros” and genuinely understanding how the network meters its own security.

The target is a finish line

The hash of a block header is a 256-bit number — a value somewhere in the range [0, 2²⁵⁶). The target is another 256-bit number that acts as a finish line: a hash wins if and only if it is less than or equal to the target.

   0 ───────────────●──────────────────────────────────────────── 2²⁵⁶
                     ▲
                  target
   |◄── winning hashes ──►|◄────────── losing hashes ────────────►|
       (rare, narrow)                  (common, vast)

Because hash outputs are uniformly spread across the whole range, the fraction of the line to the left of the target is exactly your probability of winning per hash. A smaller target means a narrower winning zone, which means more expected hashes, which means a harder puzzle. So:

Lower target = harder mining. Higher target = easier mining.

That inverse relationship trips everyone up at first. Keep it anchored: the target is a ceiling your hash must duck under, and a lower ceiling is harder to get under.

Leading-zeros intuition, and a worked comparison

Saying “below the target” is the precise rule; “starts with enough zero bits” is the friendly approximation. A target like 0000FFFF... requires the hash’s top bits to be zero. Here’s a hash that wins against a given target and one that loses:

   target :  0000 0000 FFFF FFFF FFFF ... FFFF      (everything below this wins)

   hash A :  0000 0000 9C4E 12AB 77D0 ... 03E1      ≤ target  →  VALID  ✓
   hash B :  0000 0001 0034 ...                      > target  →  reject ✗
                    ▲
            one bit too high up here, and the whole hash is already too big

Hash A squeaks under the line; hash B is barely over and is rejected. Notice that whether a hash wins is decided from the most significant bits down — which is why “number of leading zeros” is such a good shorthand. Each additional required zero bit halves the winning zone and therefore doubles the expected work.

Packing the target into 4 bytes: the bits field

A full 256-bit target is 32 bytes. Storing that in every header would be wasteful, so the header encodes the target in a compact 4-byte field called bits (also called nBits). It’s a floating-point-style format: one exponent byte and three mantissa (significand) bytes.

   bits = 0x  1d   00 ffff
              └┬┘   └──┬──┘
           exponent  coefficient (mantissa)

   target = coefficient × 256^(exponent − 3)
          = 0x00ffff × 256^(0x1d − 3)
          = 0x00ffff × 256^26
          = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

That particular value, 0x1d00ffff, is the famous genesis target — the easiest difficulty Bitcoin ever ran at, baked into the first block on 3 January 2009. To read any header’s target, you expand its bits field with the formula above; to write a new target, you re-encode it back into the compact form. Every node does this and must agree on the result, so the encoding is part of consensus, quirks and all.

A real encoding quirk worth knowing

The compact format is sign-aware: if the top bit of the mantissa would be set, an extra zero byte is prepended and the exponent bumped, to keep the value unambiguously positive. This is why the genesis mantissa is 00ffff and not ffff00. It’s a small wart inherited from the original code, but because every implementation must reproduce it bit-for-bit to stay on the same chain, it’s now permanent. Consensus rules can never be “cleaned up” without a fork.

Difficulty: a human-friendly ratio

The raw target is an ugly 256-bit number. Difficulty is the friendly version everyone quotes. It is simply a ratio comparing the easiest-ever target to the current one:

   difficulty = genesis_target / current_target

• Difficulty 1 is the genesis target (the easiest setting).
• Difficulty 2 means the current target is half the genesis target — twice as hard, twice the expected hashes per block.
• A difficulty in the trillions means each block now takes on the order of that many times more work than the very first one did.

So difficulty and target move in opposite directions: as the network gets stronger and the target is lowered, difficulty climbs. Difficulty is just a re-scaling of the same information into a number humans can compare across years.

Converting difficulty to “expected hashes”

Expected hashes per block ≈ difficulty × 2³² (about 4.29 billion × difficulty). The 2³² comes from the genesis target itself representing roughly one win per 2³² hashes. So if you know the difficulty, you can estimate the total computational effort the network spends, on average, to mine a single block — and from that, the network’s hashrate given the ~10-minute block time.

The thread

How does this help untrusting strangers agree on one ledger? The target is the single number that defines how much work “counts.” Because it’s encoded in the header and every node expands bits identically, strangers don’t have to negotiate or trust each other about how hard a block was to make — they read the threshold straight from the data and check the hash against it. Difficulty then lets them compare the weight of entire competing histories at a glance. A shared, mechanical definition of “hard” is what makes “most work wins” an objective rule rather than an opinion. Next we see how that target is adjusted over time in difficulty retargeting.

Check your understanding

1. Why does a lower target make mining harder? Phrase it in terms of the winning zone on the number line.
2. Expand the compact field 0x1d00ffff into a target using the exponent/mantissa formula. What block does this value belong to?
3. Why is the genesis mantissa stored as 00ffff rather than ffff00?
4. Define difficulty as a ratio. If difficulty doubles, what happens to the target and to the expected hashes per block?
5. Why can’t the consensus rules simply “tidy up” the compact-encoding quirk in a future release?