How proof of work works

Adjusting the difficulty target

Introduction to Bitcoin mining

Adjusting the difficulty target

Why aim for 10 minutes between blocks?
Understanding hashrate
Adjusting the difficulty target
Target representation

In previous chapters, you saw the heart of proof-of-work: miners hash the header of their candidate block with SHA256d, and the block is only considered valid if the resulting hash is numerically less than or equal to a reference value called the target. The question then remains: where does this target come from, and how does the system ensure that it remains consistent over time?

Bitcoin is aiming for an average rate of one block found every 10 minutes. Obviously, this pace isn’t guaranteed to the second. In practice, some blocks are found a few seconds after the previous one, while others are found after more than an hour. What matters here is the average over a sufficiently long period.

This variability stems from the probabilistic nature of mining: each hash is an independent attempt, with a constant probability (assuming the target remains unchanged) of producing a result below the target. It can therefore be compared to a lottery with a continuous draw: the more hashes miners make per second, the shorter the expected delay before the appearance of a valid block, but without ever eliminating the randomness from one draw to the next.

Why aim for 10 minutes between blocks?

Although there is no evidence of this, Satoshi Nakamoto surely chose 10 minutes as a practical compromise between efficiency and security. A shorter interval would give more frequent confirmations, but would cause more temporary network splits. To understand this point, we need to go back to the way a block propagates.

When a miner finds a valid block, he immediately distributes it to his peers. The nodes that receive it check its validity (transactions, proof of work, consensus rules, etc.), then relay it in turn. This propagation takes a certain amount of time, limited by internet latency, bandwidth and the ability of each node to verify the block.

If, during this diffusion delay, another miner also discovers a valid block at the same height, the network may be temporarily split: one part of the nodes and miners rely on block A, while the other rely on block B. This is a temporary division of the network.

These divisions are not catastrophic. The Nakamoto consensus predicts that, in the long term, only one branch will prevail: the one that accumulates the most work. Indeed, as soon as a new block is mined on top of block A, for example, the whole network resynchronizes on this branch and abandons block B, which then becomes a "stale block", sometimes erroneously called an "orphan block" in everyday language.

On the other hand, they have a cost: for a few minutes, a fraction of the miners work on a branch that will be abandoned. This work is then wasted from the point of view of overall security, as it has not contributed to the final chain. The faster the interval between each block, the greater the probability of such splits, since the propagation time represents a larger proportion of the time between each block.

The 10-minute interval generally allows enough time for the winning block to propagate widely before a competing block at the same height is found. It's a compromise that limits splits, reduces wasted computing power, and helps the network stay synchronized on a global scale.

Understanding hashrate

"Hashrate" refers to the amount of hash computation produced per second, whether by a single miner, a group of miners, or all miners in Bitcoin. It is expressed in H/s (hashes per second), with multiples such as TH/s (terahashes per second) or EH/s (exahashes per second). This represents the number of attempts miners can make each second to try to get a hash lower than the target.

If the target remains fixed, then:

each attempt has a fixed probability of success;
making more attempts per second increases the likelihood that a winning attempt will appear quickly

In other words, if tomorrow's Bitcoin network doubles its computing power by connecting twice as many mining machines, without a corrective mechanism, blocks would be found on average twice as fast. The target must therefore be adjusted to compensate for hashrate variations.

Adjusting the difficulty target

Bitcoin solves this problem with a periodic target adjustment mechanism, which adjusts the difficulty of mining. The principle is as follows: every 2016 blocks (approximately every 2 weeks), each node recalculates the difficulty target by observing how much time was actually needed to produce these 2016 blocks.

The aim of this mechanism is to reduce the average production time of a block to around 10 minutes, while the overall hashrate of the network is constantly changing, due to machines being disconnected or, on the contrary, new machines being added.

The calculation is based on the observed time for the period elapsed:

if the last 2016 blocks were found too quickly, this means that hashrate increased during this period; Bitcoin then makes the condition more difficult by lowering the target for the next period;
if the 2016 blocks were found too slowly, this means that hashrate has decreased; Bitcoin eases the condition by increasing the target.

The formula is as follows:

Tn = To * (Ta / Tt)

With:

tn: new target
to: old target
Ta: elapsed real time for the last 2016 blocks
Tt: target time (in seconds)

With a target time of two weeks, i.e. Tt = 1,209,600 seconds:

Tn = To * (Ta / 1 209 600)

To understand how to adjust the difficulty of Bitcoin mining, here's an example with fictitious values:

Tn = To * (Ta / 1 209 600)
Tn = 18 045 755 102 * (1 000 000 / 1 209 600)
Tn = 14 918 779 020

With:

**To = 18,045,755,102**: Old target, i.e. the reference value before adjustment.
**ta = 1,000,000 seconds**: Time actually spent producing the last 2016 blocks. Since this time is less than the target time, the network has mined too quickly.
**1,209,600 seconds**: Target time corresponding to 10 minutes per block for 2016 blocks, used as a reference for adjustment.
**tn = 14,918,779,020**: New target calculated after difficulty adjustment.

Here, the new target is lower than the old one, which means mining becomes harder in order to slow down block production in the next period.

The target values in this example are simplified and scaled for teaching purposes; the actual target used in Bitcoin is a 256-bit integer of a completely different order of magnitude.

This calculation is performed locally by each node, based on the timestamps entered in the blocks. As all nodes apply the same rules, they arrive at the same result, and the new target becomes the common reference for the next 2016 blocks.

There's an important detail to note about this adjustment: it is limited. Bitcoin limits the variation in difficulty per period in order to avoid too abrupt changes that could block it. In fact, the actual time taken into account is constrained to remain within a range equivalent to a factor of 4 (minimum one quarter of the old target, maximum four times the old target). This prevents extreme retargeting if timestamps are highly atypical or manipulated.

Note also that in reality, the Bitcoin difficulty adjustment is not perfectly accurate. Indeed, we have seen that it is designed to recalculate the difficulty every 2016 blocks, by comparing the actual elapsed time to the target time of 14 days (2016 × 10 minutes). However, Satoshi's original code contains a so-called "off-by-one" error: instead of measuring the time between the last blocks of each period (i.e., 2016 intervals), it measures the time between the first block and the last, which is only 2015 intervals. Concretely, the difficulty is calculated as if the period consisted of only 2015 blocks instead of 2016. The consequence is that the difficulty is systematically very slightly overestimated, meaning that blocks are mined on average a tiny bit slower than the target 10 minutes (about 0.05% slower). This bug is well known but has never been corrected, as modifying it would require a hard fork and its impact remains negligible in practice, outside of the theoretical attack called "time warp".

Target representation

In the block header, the target does not appear in its full 256-bit form, as this would take up too much space. Instead, the 32-bit nBits field encodes the target in a compact format, comparable to base 256 scientific notation: an exponent (1 byte) and a coefficient (3 bytes). The complete target is then reconstructed from these two values. We won't go into detail here, as the subject is relatively complex and adds nothing to the understanding of mining. Just remember that the target is not stored in raw form in the block header, but in compact form.

With this final chapter of Part I, we have taken a tour of how proof-of-work works in Bitcoin: the miner builds a candidate block by selecting transactions from its mempool, calculates the candidate block header, hashes it, compares the resulting hash with the period target, then starts again by modifying the nonce until a valid hash is obtained. Finally, every 2016 blocks, the network recalculates a new target in order to maintain an average time of around 10 minutes per block, despite the constant variations in hashrate.

Quiz

min1012.5

1/5

What average interval between blocks does Bitcoin aim for?