Bitcoin difficulty fell 10.09% as slower blocks forced a major retarget

Bitcoin’s mining difficulty fell 10.091% at block 953,568, reducing the network-wide measure from 138.96 trillion to 124.93 trillion. The block carried a timestamp of 00:23:57 UTC on June 14, 2026—5:23:57 p.m. Pacific daylight time on Coinburn’s June 13, 2026 archive date.

The reduction was an automatic protocol response to slower block production, not a decision by a company, mining pool or regulator. Bitcoin recalculates difficulty every 2,016 blocks so that blocks continue arriving approximately every ten minutes as effective mining power changes. When an epoch takes longer than intended, the next epoch begins with a less demanding proof-of-work target.

The size of the cut made the adjustment especially important for miners. With equipment, electricity prices, transaction fees and bitcoin’s market value held constant, lower difficulty increases the expected bitcoin output from each unit of active computing power. It provides mechanical relief after hashpower leaves the network, although it does not guarantee that any particular mining operation becomes profitable.

What the block establishes

Mempool.space records block 953,568 under the hash `0000000000000000000090b6c2d9f1e99b76c4c9b54d391fa9d02187425678d9`. The block was attributed to F2Pool and contained 4,878 transactions. Its header encoded difficulty of 124,932,866,006,548.16, while blocks in the preceding epoch carried difficulty of 138,955,357,012,247.30.

Subtracting those values gives a reduction of approximately 14.022 trillion difficulty units. Dividing that difference by the preceding value produces a 10.091364% decline, which Coinburn rounds to 10.091%. The calculation is deterministic once the two difficulty values are established.

Bitcoin Core’s proof-of-work implementation explains the mechanism: difficulty can change only at the configured adjustment interval, and the new target is calculated from the elapsed time represented by the preceding interval’s block timestamps. The code also limits how far difficulty can move in a single adjustment.

Block timestamps require a qualification. They are supplied by miners and constrained by Bitcoin’s consensus rules, but they are not a trusted record of the exact second when every node received a block. The June 13 classification therefore reflects the block’s encoded timestamp converted to Pacific time; under UTC dating, the same retarget belongs to June 14.

Mining stress, not a security verdict

A downward retarget establishes that the completed epoch produced blocks more slowly than Bitcoin’s target. It does not independently reveal why machines went offline. Electricity economics, equipment efficiency, planned maintenance, curtailment programs and ordinary statistical variance can all affect observed block production.

Nor did the adjustment change Bitcoin’s transaction rules, 3.125 BTC block subsidy or maximum supply. It altered the amount of expected computational work required to find a valid block. Describing it as evidence that Bitcoin had become insecure would go beyond what the block record establishes.

Market data also resists a simple causal reading. CoinMarketCap’s historical snapshot for June 13 listed bitcoin at $64,421.33, up 1.38% over its displayed 24-hour window, with reported 24-hour volume of $16.956 billion. Those figures aggregate covered venues and represent the provider’s dated snapshot rather than a universal closing price. They show the market setting around the retarget but do not prove that the adjustment caused the price movement.

Later confirmation

Reports published on June 14 characterized the 10.09% move as the second-largest downward adjustment of 2026 and the eleventh-largest in Bitcoin’s history. That ranking is later context; the event-day conclusion is narrower. Block 953,568 demonstrated Bitcoin’s automatic response after slower production: difficulty fell to 124.93 trillion and the network continued into a new 2,016-block epoch under the reduced threshold.