Target

The target is the threshold a block hash must meet. A block is valid only if its header hashes to a value at or below the target. A lower target is harder to meet, so mining takes longer. The target is recalculated every 2016 blocks, so that blocks keep arriving about once every 10 minutes, whatever the total hashing power on the network.

A recent example is the target set at block 951,552 in May 2026. Its first 24 hex digits are 00000000000000000002068f, and the remaining 40 are zeros. Its 64 digits begin with 19 zeros. The next section explains how that value is stored, and the rest of the page explains how it changes.

What does the target look like?

The target is a 256-bit number, shown as 64 hexadecimal digits. Most of those digits are leading zeros. The more leading zeros, the smaller the target, and the harder it is to find a hash below it.

Here is the target for block 100,000, from the example on the mining page:

000000000004864c000000000000000000000000000000000000000000000000

A block hash is compared with the target as a whole number. Explorers show the hash with its bytes reversed, so read it in that display order, left to right, against the target. The mining loop on the mining page does exactly this comparison.

What is the bits field?

Writing 64 hex digits into every block header would waste space, so the target is stored in the header's bits field, in a compact four-byte form. The first byte is an exponent, and the other three bytes are a mantissa.

def bits_to_target(bits: int) -> int:
    exponent = bits >> 24           # the number of bytes in the target
    mantissa = bits & 0xFFFFFF      # the top three bytes of the target
    return mantissa * 256 ** (exponent - 3)

print(format(bits_to_target(0x1B04864C), "064x"))
# 000000000004864c000000000000000000000000000000000000000000000000

For block 100,000, the bits are 1b04864c. The exponent 1b is 27, so the mantissa 04864c is shifted left by 24 bytes, and the result is the 64-digit target above. The sketch leaves out one edge case in Bitcoin Core, which rejects a mantissa with its top bit set, since that would be a negative target. No valid block uses that form, so the sketch can skip it.

What is difficulty?

Difficulty is a more readable way to express the target. It is the ratio of the easiest possible target to the current one:

# the target of the genesis block
DIFFICULTY_1 = bits_to_target(0x1D00FFFF)

def difficulty(bits: int) -> float:
    return DIFFICULTY_1 / bits_to_target(bits)

# block 100,000 gives 14484.16
print(round(difficulty(0x1B04864C), 2))
# block 951,552 gives 138955357012247.3
print(round(difficulty(0x1702068F), 2))

The easiest possible target, 00000000ffff0000…, has difficulty 1. The difficulty of block 100,000 is about 14,484, which means its target is about 14,484 times smaller than the genesis target. On average, a miner needs about the difficulty times 2^32 hashes per block. At block 100,000 that is about 62 trillion. Converting a difficulty value back into a target is not exact, because difficulty is stored as a floating-point number. The difficulty word page covers the idea in plain words.

When does the target change?

The target changes every 2016 blocks, which is about two weeks at the target pace. When a retarget is due, every node looks at the timestamps of the last period and compares them with the time expected for it.

The expected time is 2016 blocks at 600 seconds each, which is 1,209,600 seconds. The timestamps are taken from the first block of the period and the last block of the period. That span contains 2015 intervals, not 2016. The period is therefore one interval short. The original code made that choice, and it stays because changing it would change the rules every node follows.

When miners join or leave, the actual time moves away from the expected time, and the next adjustment pulls it back. Nothing needs to be told to the nodes. Each one reads the timestamps and reaches the same result.

How is the new target calculated?

The new target is the old target multiplied by the ratio of the actual time to the expected time. Here is the calculation as a sketch, in whole-number arithmetic like Bitcoin Core's.

# the easiest target, set at genesis
MAX_TARGET = bits_to_target(0x1D00FFFF)

def next_target(old_target: int, first_time: int, last_time: int) -> int:
    # two weeks at ten minutes a block
    expected = 2016 * 600
    # the 2015 intervals of the period
    actual = last_time - first_time
    # never change by more than four times
    actual = min(max(actual, expected // 4), expected * 4)
    return min(old_target * actual // expected, MAX_TARGET)

The final value still has to be stored in the compact bits form, which drops the low digits.

The worked example uses the period from block 401,184 to block 403,199. Its timestamps give an actual time of 1,157,929 seconds. The ratio is 1,157,929 divided by 1,209,600, which is 0.9573. The period was faster than expected, so the target falls and mining gets harder. The old bits, 1806f0a8, become 1806a4c3 for block 403,200. The new target is about 4.3% smaller than the old one, so the difficulty rises by about 4.5%.

What limits a change?

Two limits keep the target sane.

1. The change is at most a factor of four. If the ratio is below 0.25 or above 4, it is clamped to that value. A period of very fast blocks cannot make the target four times smaller than before. A very slow period cannot make it four times larger. Either way, the change happens in a single step.
2. The target never goes above the genesis target. The genesis target, 00000000ffff0000…, is both the starting point and the largest value a target can take. It is the easiest a block can be.

The second limit explains why the target sat still at the start. The first 2016 blocks took about 24 days, far longer than the 14 days expected. Each adjustment then wanted to make mining easier, but the target was already at its maximum. The first real change came at block 32,256, when the difficulty rose from 1 to about 1.18.

What are some recent target changes?

Here are three recent adjustments, with the height where each new target took effect.

Height	Target (first 24 digits)	Change from the previous period
951,552	00000000000000000002068f	×0.9831
949,536	000000000000000000020f79	×0.9697
947,520	000000000000000000021ff0	×1.0236

Each change is the new target divided by the target of the period before it. A ratio below 1 means the difficulty rose, and a ratio above 1 means it fell. You can confirm any row against its block on our explorer, for example block 951,552.

Why 10 minutes?

The white paper does not say why the interval is 10 minutes. The usual reasoning is that blocks must have time to reach every node before the next one is found. If they were mined much faster than they propagate, miners would keep building on stale blocks, and some work would be wasted in short forks. A steady interval also gives a steady rate of new coins.

How do nodes agree on the target?

Each node calculates the target on its own, and each one reaches the same answer. Every node follows the longest chain of valid blocks, and the target depends only on the timestamps and targets in that chain. Two nodes with the same chain therefore hold the same target at every height.

How can you read the current target?

Bitcoin Core can give you the target in three ways.

• getblocktemplate returns the target for the next block, which is the most direct answer. Use it with the segwit rule, as on the candidate block page.
• getblockheader returns the bits value for any block. Convert it with the sketch above to get the full target.
• getdifficulty returns the difficulty. It is handy for a quick look, but as noted above, converting it back to a target is not exact.

For a block that already exists, the bits value in its header is the target it was mined against, and that is the value a node checks.