Bitcoin Difficulty Jumped 14.95% in a Post-Halving Rebound

Bitcoin’s mining difficulty increased 14.95% at block 635,040 on June 16, 2020, the network’s largest upward adjustment since January 2018. The retarget raised difficulty from approximately 13.73 trillion to 15.78 trillion, sharply increasing the computational work miners would, on average, need to perform to win a block during the new adjustment period.

The change mattered because it followed the May 11 reduction of Bitcoin’s block subsidy from 12.5 BTC to 6.25 BTC. That halving immediately reduced the new bitcoin available to miners for each valid block, while two subsequent difficulty declines reflected slower block production as the network adapted. The June 16 increase showed that the completed adjustment period had instead run substantially faster than Bitcoin’s target pace.

The narrow conclusion is that aggregate mining competition had recovered strongly enough for the protocol to impose a harder proof-of-work target. The retarget did not reveal which companies or machines supplied that computing power, whether every operator was profitable, or whether the increase would persist.

What changed at block 635,040

Bitcoin recalculates its proof-of-work target every 2,016 blocks, approximately once every two weeks. The consensus calculation compares the timestamp span from the completed adjustment period with the protocol’s target duration. If blocks arrived faster than intended, the target becomes harder; if they arrived more slowly, it becomes easier.

The difficulty applicable before block 635,040 was approximately 13,732,352,106,018.34. The new figure was approximately 15,784,744,305,477.41. Dividing the latter by the former and subtracting one gives a calculated increase of 14.9457%, conventionally rounded to 14.95%.

Difficulty is a dimensionless comparison with Bitcoin’s easiest proof-of-work target. It is not a direct reading of electricity consumption, machine count or instantaneous hashrate. Hashrate must be estimated from the probabilistic pace of block discovery, while difficulty is encoded through the target represented in block headers.

Contemporaneous reporting placed the retarget at approximately 17:00 UTC on June 16. Block timestamps are supplied by miners within protocol constraints, however, and do not establish the exact moment every node received the block.

A reversal after the halving

The June 16 retarget reversed two consecutive declines following the subsidy reduction. Difficulty had fallen about 6% on May 20 and another 9.29% at block 633,024 on June 4. Those reductions made it easier to find valid blocks after the preceding periods ran more slowly than targeted.

The subsequent 14.95% increase did not restore the 12.5 BTC subsidy or increase the scheduled number of new coins paid per block. Instead, it intensified competition for the reduced 6.25 BTC subsidy and the transaction fees included in each block. A miner maintaining the same hashrate would therefore expect a smaller share of block discoveries after the adjustment, all else equal.

For mining businesses, the economic effect depended on variables the blockchain could not settle: equipment efficiency, electricity prices, uptime, pool performance, transaction fees, financing costs and bitcoin’s exchange value. The retarget was therefore a network-wide competitive signal, not a universal measure of miner profitability.

What the record establishes

The block record establishes that height 635,040 introduced the harder target. Bitcoin Core’s contemporaneous proof-of-work implementation establishes the governing adjustment rule, while reports published on June 16 independently recorded the new difficulty and its historical ranking.

The claim that the increase reflected renewed aggregate computing competition is an interpretation of the completed adjustment window. It should not be expanded into claims that all miners had returned, that the network’s geographic distribution had improved, or that the adjustment caused a bitcoin price move. No spot-price or trading-volume claim is made because the retarget itself does not establish either relationship.