Target and difficulty

Mining is a lottery. Miners buy tickets with work, and a ticket wins if its number is small enough. The target is that “small enough”: a 256-bit number that a winning ticket must not exceed.

The target is the knob that sets the pace. Lower it and winning tickets get rarer, so blocks take longer. Raise it and they come faster. Pearl turns this knob a tiny bit after every block, to keep about one block every 194 seconds.

Difficulty is the same knob, written for humans: one friendly number that says how many times harder today’s target is than the easiest one allowed.

Try it

Type a bits value and see the target it stands for and its difficulty. Start with block 130,827’s 0x176af3a6, then try 0x1b00ffff.

Bits, target and difficulty

Three ways to write how hard a block is

Bits 4 bytes, in the header

Difficulty vs. 0x1b00ffff

Target 256-bit number, hex

How bits encode the target

17 6a f3 a6

target = 0x6af3a6 × 256^{23 − 3} : the exponent says the target is 23 bytes long; the mantissa gives its first 3 bytes, the rest are zeros.

0000000000000000006af3a60000000000000000000000000000000000000000

Difficulty

40,157,376.49334089

The PowLimit target (difficulty 1) ÷ this target.

Target

0000000000000000006af3a60000000000000000000000000000000000000000

How small the target is, on a log scale from 1 to 2²⁵⁶

The target is about 2^182.7. A random 256-bit number lands below it about once in 1.13 × 10²² tries. Each step left on this bar is a doubling of difficulty. Expected work per block (chain work) is 2²⁵⁶ ÷ (target + 1) ≈ 2^73.3.

Pearl: nothing is compared with this target alone. A block wins when its certificate’s BLAKE3 ticket is at most target × the work in one tile, and the block hash is never checked against it.

Runs in your browser · nothing is sent src/lib/block.ts · btcd’s CompactToBig / BigToCompact

Why does a blockchain need a target at all?

Because mining power never sits still. If the bar were fixed, twice as many GPUs would mean blocks twice as fast, and half as many would mean blocks twice as slow.

A moving target fixes that. When blocks come too quickly, the target shrinks and tickets need to be smaller. When they come too slowly, it grows. The pace stays near 194 seconds whatever the miners do, and so does the schedule of new coins, which counts blocks.

What does the target judge on Pearl?

Not the block hash. This is the biggest difference from Bitcoin. A Pearl block hash is a big, random-looking number, nowhere near the target.

The target judges a ticket inside the block’s certificate: a BLAKE3 hash of one tile of the miner’s matrix work. And the bar is scaled by how much work that tile cost:

\text{ticket} \le \text{target} \times h \cdot w \cdot L

h·w is the number of cells in the tile and L the length of each cell's sum. Block 130,827: 8 × 16 × 8,192 = 1,048,576.

Scaling the bar by the tile’s work means a big tile and a small tile cost the same per unit of work to win with. The whole check, with real numbers, is on tickets and target.

How do bits, target and difficulty fit together?

They are three views of one number.

One value, three views. The header stores bits; nodes decode it to a 256-bit target; explorers show it as a difficulty. Block 130,827.

Bits is how the header stores the target: 4 bytes, an exponent and three digits, like scientific notation. Decoding it by hand is on bits.
Target is the real 256-bit number nodes compare with.
Difficulty divides the easiest target by the current one:

\text{difficulty} = \frac{\text{target}(\texttt{0x1b00ffff})}{\text{target}(\text{bits})}

Same formula as Bitcoin, different reference

Bigger difficulty, smaller target, harder block. Here is how it climbed on Pearl’s mainnet:

Block	Bits	Difficulty
0 and 1	`0x1b00ffff`	1.00000000
2	`0x1b00ffea`	1.00032054
2,017	`0x1b008475`	1.93267274
10,000	`0x1a0ab2a8`	23.92961877
100,000	`0x1800c4ef`	21,808,883.27997620
120,000	`0x180089e0`	31,150,692.72892112
130,827	`0x176af3a6`	40,157,376.49334089

The live figure right now is 40.16 million.

What is the easiest target allowed?

Pearl’s proof-of-work limit is 2²⁰⁸ − 1: a target with 48 leading zero bits. No block may have a bigger target.

In compact form that limit becomes 0x1b00ffff, which decodes to 0xffff × 2¹⁹², a hair below 2²⁰⁸ − 1. That value is the reference for “difficulty 1”. Pearl’s genesis block and block 1 used it.

How much work does a difficulty stand for?

On average, a block at difficulty 1 takes about 281,479,271,743,489 attempts’ worth of work: 2²⁵⁶ divided by the target. Each step of difficulty adds the same again. So block 130,827, at difficulty 40,157,376.49, stood for about 1.13 × 10²² units of work.

Because Pearl scales each ticket’s bar by its tile’s work, that unit works out to roughly one multiply-accumulate. That’s an inference from the design rather than a number Pearl publishes, and it’s the basis of Pearl’s “hashrate”. See chain work.

Who moves the target?

Nobody, by hand. Every node runs the same rule, WTEMA, after every block. If the last block took longer than 194 seconds, the target grows a little. If it was quicker, it shrinks a little. Each step is tiny: one second off schedule moves the target by one part in 604,800.

Make a guess

Mining power suddenly doubles and stays that way. After one hour, how much higher is the difficulty?

Think of your answer first, then check it.

Answer About 0.6%.

In a simple model where every block arrives exactly when the mining power predicts, about 38 blocks arrive in that hour, each roughly 97 seconds early, and each nudges the target down a hair. The difficulty is up 0.61%. After one day it’s up about 13%, and it reaches half of the needed rise after about 4.85 days. That patience is deliberate: it keeps luck and timestamp games from yanking the difficulty around. The details are on WTEMA.

The rule only works if block times are honest enough, which is why Pearl’s timestamp rules are strict. And when chains compete, the target also decides which one wins: nodes follow the one with the most chain work.

Why difficulty 1 is 0x1b00ffff and not exactly 2²⁰⁸ − 1

The compact format keeps only three bytes of mantissa and always rounds down. 2²⁰⁸ − 1 is 26 bytes of ff. Its top byte has the high bit set, which the format reads as a minus sign, so the encoder adds a leading 00: the number is now 27 bytes long (exponent 0x1b) and its top three bytes are 00 ff ff. That gives 0x1b00ffff, which decodes to 0xffff × 2¹⁹². Pearl’s code stores both: PowLimit (the exact limit a target is checked against, in params.go (node/chaincfg/params.go:27-29 at v1.5.2, on GitHub)) and PowLimitBits (the compact form used for genesis and as the difficulty reference). The difficulty explorers show comes from getDifficultyRatio (node/rpcserver.go:1034-1050 at v1.5.2, on GitHub):

node/rpcserver.go Go

max := blockchain.CompactToBig(params.PowLimitBits)   // 0x1b00ffff on mainnet
target := blockchain.CompactToBig(bits)
difficulty := new(big.Rat).SetFrac(max, target)
outString := difficulty.FloatString(8)