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.
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.
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.