Bitcoin Difficulty: Why Hashrate Does Not Set the Block Time

Difficulty is a measure of how difficult it is to find a hash below a given target. The network has one global difficulty, and a block is only valid if its hash falls under the current target.

That is the whole mechanism in one line, but the interesting behaviour is in the feedback loop around it: the target is not fixed, and the thing that moves it is time.

The rule

The difficulty is adjusted every 2,016 blocks based on how long the previous 2,016 blocks took to find. At the desired rate of one block every ten minutes, 2,016 blocks take exactly two weeks.

So the comparison is simple in form:

• Previous 2,016 blocks took longer than two weeks → difficulty is reduced.
• Previous 2,016 blocks took less than two weeks → difficulty is increased.

The size of the change is proportional to how far the actual time was from two weeks. A period that ran 10% fast produces roughly a 10% increase.

The block page describes the same rule from the other direction: the difficulty of the puzzle is adjusted automatically so that the network targets an average of six blocks per hour, and every 2,016 blocks all clients compare the actual number created against that goal and modify the target by the percentage by which it varied.

What difficulty actually is

Underneath the label is a number comparison. To find a block, the hash must be less than the target, and a hash is effectively a random number between 0 and 2²⁵⁶−1. Lowering the target makes the winning range smaller, which means more attempts are needed per success.

The wiki gives the arithmetic. The offset for difficulty 1 is:

0xffff * 2**208

and for difficulty D it is:

(0xffff * 2**208) / D

So expected hashes to find a block at difficulty D is D × 2⁵⁶ ÷ (0xffff × 2²⁰⁸), which simplifies to roughly D × 2⁴⁸ ÷ 0xffff.

Difficulty 1 itself is defined by a packed target of 0x1d00ffff in the block header, which is the highest possible target. Everything else is relative to that reference.

The direction people get backwards

It is common to hear that rising hashrate makes bitcoin “harder to mine”, as though difficulty were an independent force. The causal chain runs the other way.

Hashrate is the number of attempts per second the network is making. The target is set by the retarget rule. When hashrate rises, blocks arrive more often than one per ten minutes — for a while. Then the retarget compares the previous 2,016 blocks against two weeks, sees they came too fast, and lowers the target. The extra hashrate is absorbed, and the ten-minute average is restored.

The wiki expresses the relationship as a hash rate estimate. Over the previous 2,016 blocks, the network was computing (D × 2⁴⁸ ÷ 0xffff) hashes in 600 seconds, which simplifies to about D × 2³² ÷ 600. At difficulty 1 that is roughly 7 Mhash/s.

That means difficulty is not just a difficulty. It is a trailing estimate of how much mining power was applied during the last period — a public record of work performed, written into the protocol.

What it says about your own mining

The same arithmetic answers the individual miner’s question. Average time to find a block is approximately:

time = difficulty * 2**32 / hashrate

where hashrate is what your hardware computes per second and time is in seconds. The wiki’s example: a 1 Ghash/s rig at difficulty 20,000 comes out at just under 24 hours on average.

The word “average” is carrying a lot. The wiki is blunt that any single grinding of the hash has the same chance of winning as any other, that the numbers game is about how many attempts per second your hardware makes, and that there are no guarantees you will win within any number of days. Treating an average as a deadline is the gambler’s fallacy in mining clothing.

Can it go down?

Yes, and the wiki says so plainly. Difficulty follows the measured time, so a period of miner capitulation — hardware leaving the network — produces slower blocks and therefore a lower difficulty at the next retarget.

The floor is 1, corresponding to the maximum allowed target. The upper end is effectively unbounded: the wiki notes the theoretical maximum is enormous, around 2²²⁴, and that it would only be reached if the target were zero, which the protocol will not produce.

That asymmetry is worth noticing. There is a hard stop on how easy mining can get and no practical stop on how hard.

Why not retarget more often?

The wiki poses the question of why the difficulty is not updated more frequently and points to the long-running discussion rather than settling it in a paragraph. What can be said from the mechanism itself is the shape of the trade-off.

A shorter retarget window makes block spacing track sudden hashrate changes more closely. It also means the target is recomputed from less data, and a target is a security parameter: an entity that can move hashrate within the window can move the target that everyone else then mines against. A two-week window is long enough that gaming it is expensive and short enough that the difficulty does not stay badly wrong for long.

That is the same design logic that shows up elsewhere in the protocol: prefer a slow, predictable correction that every node can verify over a fast one that depends on measuring correctly in a hurry.

Reading difficulty as information

Three practical readings follow from the mechanism:

• It is a record of past work, not of future intent. A rising difficulty says the previous period was mined fast. It does not say anything about the next halving’s price.
• It is a self-correcting number. Charts of difficulty going vertical are showing the rule absorbing more hashrate, not a network struggling. A difficulty drop is the network absorbing an exit.
• It is only one of Bitcoin’s two adjustment clocks. The halving changes how much a block pays every 210,000 blocks; the difficulty retarget changes how hard a block is to find every 2,016. Confusing them produces forecasts that are wrong for the right reasons.