Bitcoin Difficulty Adjustment Explained

Bitcoin's difficulty adjustment resets how hard it is to mine a block once every 2,016 blocks, so that blocks keep arriving about every ten minutes however much computing power joins or leaves. If the last period ran fast, difficulty rises by the same proportion; if it ran slow, difficulty falls. On October 16, 2026, at block 971,712, it rose 5.92 percent because the previous 2,016 blocks took 13.2 days instead of 14.

That one sentence covers what most people need. The rest of this guide is for anyone who wants to check the arithmetic, read a difficulty chart without being fooled by it, or understand the edge cases that protocol developers still argue about. We work through a real retarget using block data pulled from the mempool.space explorer on October 21, 2026, and every rule is quoted from Bitcoin Core's source code as published on GitHub and checked the same day.

The Rule, Stated Precisely

Bitcoin Core's mainnet parameters set a target block spacing of 600 seconds and a target timespan of two weeks, 1,209,600 seconds. Dividing one by the other gives the retarget interval: 2,016 blocks. At the last block of each 2,016-block period, every node computes the next target from three inputs:

The new target is the old target multiplied by the actual timespan and divided by the intended two weeks. Difficulty is the inverse view of the same thing: a lower target means fewer acceptable hashes, which means higher difficulty. So when blocks came too fast, the target shrinks and difficulty rises in proportion.

There is one clamp. Before that multiplication, the code limits the measured timespan to no less than a quarter of two weeks and no more than four times two weeks. A single retarget can therefore raise difficulty at most fourfold or cut it to a quarter. On mainnet in 2026 that clamp is never close to binding, because hashrate does not change that fast, but it limits the damage of extreme events or manipulated timestamps.

Every node runs this calculation independently and gets the same answer. A block that does not meet the new target is invalid, no matter who mined it. There is no committee and no vote involved.

A Real Retarget, Step by Step

Here is the October 2026 adjustment worked from the raw block headers.

Source: mempool.space block API, pulled October 21, 2026.

The arithmetic:

The tiny gap between prediction and observation is a rounding effect of the compact "bits" format that stores the target in each header. The header field changed from 0x17021ef0 to 0x17020093. The leading byte (0x17) stayed the same, so the change sits in the remaining three bytes: 0x021ef0 is 138,992 and 0x020093 is 131,219, and 138,992 divided by 131,219 is 1.0592, the same ratio again. The target got about 5.6 percent smaller, so difficulty went up about 5.9 percent.

The off-by-one in that table

Look at the first block again. The period being measured is blocks 969,696 to 971,711, which is 2,016 blocks. But the timespan runs from the timestamp of block 969,696 to the timestamp of block 971,711, which covers only 2,015 block intervals. Bitcoin Core's code says as much: it goes back the adjustment interval minus one to find the first block. The protocol divides a 2,015-interval measurement by a 2,016-interval target.

The practical effect is a small upward bias in block time of about 0.05 percent, a few tenths of a second per block. It has been there since 2009 and changing it would require a consensus change. It matters mostly because it is the reason a well-known attack exists, covered below.

Converting Difficulty Into Hashrate

Nobody can count the hashes performed worldwide. What can be computed is the hashrate that would, on average, find blocks at the target pace given the current difficulty. The standard conversion is:

Implied hashrate = difficulty x 2^32 / 600

The 2^32 comes from how difficulty is defined: difficulty 1 corresponds to the easiest target the protocol allows (header bits 0x1d00ffff on mainnet), which requires about 2^32 hashes per block on average. The 600 is the target spacing in seconds.

Computed by CryptosEyes from block difficulty.

So the October 16 retarget put the network's implied hashrate back above 1,000 exahashes per second, one zettahash. It is not a first: mempool.space's adjustment history shows difficulty above 155 trillion, about 1,117 EH/s implied, earlier in the chain. The figure is a calculation, not a meter reading, and it describes the hashrate that was already working during the previous two weeks.

Two consequences of this method are worth keeping in mind. First, implied hashrate only changes at retargets, so a chart that updates daily is using a different estimate, usually recent block times multiplied by current difficulty, which is noisy. Second, a hashrate estimate from a few days of blocks carries real luck. Each block is a random event, so even with constant hashrate, block times vary.

How Much of a Retarget Is Luck?

Block discovery behaves like a random process with a fixed average rate. For a 2,015-interval measurement, the standard deviation of the total timespan from pure chance is about the average divided by the square root of 2,015, or about 2.2 percent. In plain terms: with no change at all in hashrate, roughly one retarget in three would still move difficulty by more than 2 percent up or down, just from luck.

Thresholds are a CryptosEyes rule of thumb derived from the 2.2 percent figure, not a protocol rule.

This is why miners and analysts look at several retargets in a row. A single number can mislead. A run of consistent increases or decreases is the signal.

Estimating the Next Adjustment

Explorers publish a live estimate. On October 21, 2026, mempool.space showed the current period (which began at block 971,712) 42.3 percent complete, with 1,164 blocks to go to the next retarget at block 973,728. Recent blocks were averaging about 571 seconds, or 9 minutes 31 seconds, and the explorer projected a rise of about 5.1 percent, with the retarget estimated for October 29, 2026.

That estimate is simply the same formula applied to the blocks so far. It moves every block. The earlier in a period you look, the noisier it is, because the luck component is larger over fewer blocks. Treat estimates in the first few days of a period as rough, and estimates in the last two days as fairly reliable.

You can do the arithmetic yourself. Take the average block time so far in the period, divide 600 by it, and subtract one. At 571 seconds: 600 divided by 571 is 1.0508, about a 5 percent increase, matching the explorer's figure.

Worked Scenario: A Sudden 20 Percent Hashrate Drop

An illustration with stated inputs. Suppose that halfway through a period, after 1,008 blocks at exactly ten minutes each, 20 percent of hashrate switches off and stays off, for example because a region curtails mining during a heat wave.

At the retarget, the rule sees a period that ran about 12.5 percent long and lowers difficulty by roughly 11 percent (14 divided by 15.75 is 0.889). That is not enough to restore ten-minute blocks for the remaining 80 percent of hashrate, which would need a 20 percent cut. The next period therefore also runs slow, at about 11.1 minutes per block (10 minutes times 0.889 divided by 0.8), and the following retarget lowers difficulty again. The network converges on ten minutes over two periods instead of one.

The lesson generalizes. Difficulty is a lagging average. A sharp change in hashrate partway through a period is only partly corrected at the next retarget, and fully absorbed one period later. For users this shows up as slower confirmations for a few weeks. For miners who stayed on, it is a temporary bonus: they find a larger share of blocks at a difficulty that has not yet caught up.

What a Retarget Does to a Miner's Income

For a single miner, difficulty is a price. Expected blocks found are the miner's hashrate divided by the network's implied hashrate, times the number of blocks. When difficulty rises and the miner's own fleet does not change, its share of blocks falls in proportion.

A worked illustration using the October 2026 numbers. A miner running 10 EH/s through the period that began at block 969,696 faced an implied network hashrate of about 950 EH/s, a share of about 1.05 percent. After the October 16 retarget, the same 10 EH/s faced about 1,006 EH/s, a share of about 0.99 percent. Expected blocks per day at the target pace fell from about 1.52 to about 1.43, a drop of about 5.6 percent, which is 1 divided by 1.0592, minus one.

Illustration by CryptosEyes. Fees use the mempool.space one-month average per block to October 21, 2026.

Nothing changed for this miner except that the rest of the network grew. That is the treadmill miners describe: holding income steady in bitcoin terms requires growing your hashrate as fast as everyone else's. When combined with the halving, which cuts the subsidy in half on a fixed date, it explains why fleet efficiency and power cost decide which operators last. The miner and treasury company pages on this site track holdings for the public miners, and our mNAV guide explains how the market prices them.

Why Two Weeks?

The two-week window is a compromise, and the trade-off is easy to see in the luck figure above. A longer window averages out more luck but reacts more slowly to real changes. A shorter one reacts faster but is noisier and easier to game with timestamps. With 2,016 blocks, the random error is about 2.2 percent, small enough that the retarget mostly tracks real hashrate, while the delay before a correction is at most two weeks at normal pace.

Some other proof-of-work chains adjust difficulty every block using a moving average. That reacts within minutes but creates other problems, such as oscillation when miners hop between chains. Bitcoin's interval has never been changed. Changing it would be a consensus change that every node would have to adopt.

What Difficulty Does Not Tell You

Edge Cases Developers Still Discuss

The timewarp attack

Block timestamps are allowed to be loose. A block's time must be later than the median of the previous 11 blocks and no more than two hours ahead of the validating node's clock, according to Bitcoin Core's chain rules. That flexibility is needed because clocks differ, but it leaves room for games.

The timewarp attack combines that freedom with the off-by-one above. Because each period's timespan is measured from inside the period, and the gap between the last block of one period and the first block of the next is never measured, a miner with a large share of hashrate could keep timestamps low within periods while pushing the boundary block's timestamp forward. Each retarget would see an artificially long timespan and lower difficulty, letting blocks come faster and faster. It would take sustained majority hashrate and would be visible to everyone, which is why it has stayed theoretical on mainnet.

Bitcoin Core's code contains a fix for one of its test networks. The mainnet parameter for that rule (BIP 94) is set to false in the source checked on October 21, 2026. Proposals to close the hole on mainnet through a soft fork have been discussed by developers for years, and none had been activated as of that check.

Sudden large hashrate drops

If a large share of hashrate disappears, for example during a regional power cut, blocks slow down until the next retarget. In the worst case, a 50 percent drop early in a period would roughly double block times for the rest of it, stretching that period toward four weeks. The rule cannot react faster than one period. This is a real limit of the design. It has been tolerable because hashrate is spread across many regions and operators.

The minimum difficulty

The protocol defines an easiest permitted target, encoded as the "powLimit" in Bitcoin Core's mainnet parameters. Difficulty cannot fall below the level corresponding to that target. On mainnet in 2026 this is irrelevant, since current difficulty is about 140 trillion times higher, but it matters for test networks.

Common Mistakes

A Short Monitoring Routine

Frequently Asked Questions

How often does Bitcoin's mining difficulty adjust?

Every 2,016 blocks. At the ten-minute target that is two weeks, but because blocks usually arrive slightly faster as hashrate grows, the real interval is often a little shorter. The October 2026 period took about 13 days and 5 hours.

What is the maximum difficulty change in one adjustment?

A factor of four in either direction. Bitcoin Core limits the measured timespan to between one quarter and four times the two-week target before computing the new value.

Why did Bitcoin difficulty rise in October 2026?

The 2,016 blocks before block 971,712 arrived in about 13.2 days instead of 14, an average of about 9 minutes 27 seconds per block, so difficulty rose 5.92 percent to bring the pace back toward ten minutes. That points to more hashrate joining during early October.

Does higher difficulty make transactions slower or more expensive?

No. Difficulty only keeps average block times near ten minutes. Transaction fees depend on demand for block space, not on how hard blocks are to mine.

How is hashrate calculated from difficulty?

Multiply difficulty by 2 to the 32nd power and divide by 600 seconds. At the October 16, 2026 difficulty of about 140.58 trillion, that gives about 1,006 exahashes per second. It is an estimate of the average hashrate implied by the difficulty, not a measured total.

Could someone game the difficulty adjustment?

The timewarp attack shows it is possible in theory for a miner with sustained majority hashrate, by manipulating timestamps at period boundaries. It would be slow and visible, and it has never been carried out on mainnet. A mainnet fix has been proposed but was not active as of October 21, 2026.

Where This Fits

Difficulty is one of three moving parts in Bitcoin's supply and security picture, alongside the subsidy schedule and the fee market. The fastest way to see how they interact is our halving history guide, which uses the same block data to show issuance, difficulty and fees across all four halvings, including a worked example of what the next halving does to a 1 EH/s miner. For the underlying concepts, see proof of work vs. proof of stake and how a blockchain works. The rest of our Bitcoin explainers are in the research library.

CryptosEyes publishes educational research, not financial advice. Difficulty and hashrate figures are dated snapshots; the next retarget estimate changes with every block.