How does the mechanism work?

Miners repeatedly vary candidate data and hash the resulting headers. There is no requirement to get gradually closer with each attempt. A different input gives another result to check against the threshold.

On the main network, the target adjustment uses intervals of 2,016 blocks and aims for an average block interval of about 10 minutes. The algorithm limits adjustment changes. These are protocol targets, not a schedule promising the next block at a particular moment.

Retargeting and chain selection should not be conflated. Retargeting establishes the required threshold for an upcoming part of a history under that history’s rules. Chain selection compares accumulated work across histories that pass validation. A node needs the expected target when deciding whether a header contributes valid work at all. Someone cannot choose an easier target in the header, satisfy it and claim the result deserves acceptance. Nor should an interface compare only the count of visible leading zeros without interpreting the target. The source code defines the numeric comparison and the encoding needed to make this assessment precise.

A candidate hash must satisfy the targetMiners try candidate block headers. A hash must be less than or equal to the target. Even a qualifying hash does not excuse invalid transactions; nodes also validate the block.Hash candidate headerAbove target:retryMeets target:checkSeparate roles, shared context
A qualifying hash passes a work check. Full block validation still has to pass.

What would you see in an example?

Imagine lowering the target while leaving the set of possible hash results unchanged. Fewer results now qualify. A miner must expect more trials, but an individual trial can still succeed quickly or fail. Once a qualifying candidate is broadcast, a full node also checks the transactions and every other applicable block rule.

What does the retarget calculation aim to preserve?

On the main network, the nominal retarget span is 2,016 × 600 seconds, or 1,209,600 seconds. The intended spacing is 600 seconds per block on average. These constants describe a probabilistic process and its adjustment rule. They do not mean a node can reject a block merely because the previous one arrived less than ten minutes earlier.

Use a simplified worked retarget example. Suppose the measured timespan used by the algorithm is 604,800 seconds, half the nominal span. Ignoring compact-encoding rounding and the maximum target, multiply the old target by 604,800 / 1,209,600. The new target is half as large, so difficulty roughly doubles. Fewer header hashes meet a lower threshold.

The implementation bounds the timespan used for this adjustment between one quarter and four times the nominal span. These limits constrain an individual adjustment. They do not set a maximum or minimum time for each block. Exact results depend on integer arithmetic, compact-target representation and the network’s rules. Use the source calculation when checking an actual boundary rather than applying a rounded percentage.

Work and height answer different questions. Height counts blocks from the beginning of a particular history; accumulated work accounts for the difficulty of those blocks. Nodes select among valid candidate histories using accumulated work. A longer sequence of easier blocks is therefore not automatically the preferred chain. Every block must still satisfy its expected target and the other applicable rules.

Worked mechanism sequenceUse a simplified worked retarget example. Suppose the measured timespan used by the algorithm is 604,800 seconds, half the nominal span. Ignoring compact-encoding rounding and the maximum target, multiply the old target by 604,800 / 1,209,600. The new target is half as large, so difficulty roughly doubles. Fewer header hashes meet a lower threshold.Measure interval timespanClamp permitted adjustmentCalculate next target
Follow the example in the text. Monetary amounts and fee rates are invented, not live observations.

Common misunderstandings

A miner does not submit an energy bill that a node verifies. The node checks a compact mathematical proof: the candidate header’s hash satisfies the required threshold. Energy and hardware are part of producing attempts, not extra header fields.

More attempts do not make the next individual hash remember past failures. Nor does a successful proof authorise a miner to alter spending rules or create an excessive subsidy. Work comparison happens within the set of valid histories; an invalid block stays invalid regardless of its hash.

Check yourself

If the target halves, does a fixed header have two chances to pass?

Reveal the answer

No. Its hash is fixed. A smaller target admits fewer possible results; miners need to try different candidate bytes to obtain different hashes.

What does this diagram leave out?

Difficulty is not a measure of transaction correctness or a guarantee about an asset’s value. Finding proof of work for an invalid block cannot force a validating node to accept it. The diagram omits retarget arithmetic and specialised network rules; the sources define those details.

In the Bitcoin family

The Bitcoin Ecosystem project describes Bitcoin Genesis 1 (BTC1) as “The Decentralised Utility & Security Chain (proof-of-work)”, with supply wording “26.6 Million per year”. The project describes its purpose as a decentralised system with stakes in companies holding real-world assets, support for a public currency and a highly secure network for general-purpose utility and peer-to-peer interactions and transactions.

Which primary sources explain the rules?

Sources: Proof-of-work target calculation; Network consensus parameters; Block chain developer guide.

Sources: Retarget bounds and integer calculation; Main-network timing parameters.

Source: Bitcoin Ecosystem project descriptions.