Bitcoin difficulty rises 5.92% to 140.58 trillion at block 971712
Source report: 2026-10-16 · Editorial analysis published: 2026-10-17
Block records confirm the October 16 adjustment. For unchanged hashrate, expected subsidy output per unit of time falls about 5.59% under otherwise fixed assumptions; that is not a forecast of net profit.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
A completed adjustment, not a forecast
Bitcoin moved to a difficulty of approximately 140.58 trillion at block 971712. Mempool.space's block API dates that block to October 16 at 12:37:31 UTC. The preceding epoch's first block, 969696, records approximately 132.72 trillion. Comparing the unrounded values gives an increase of 5.9236848%.
The October 17 check found the chain beyond the boundary, at height 971825, and the difficulty-adjustment endpoint reported the same previous change. This verifies a completed event. Estimates published before block 971712 were forecasts and should not replace the realized value or its block timestamp.
Difficulty is a target parameter
Difficulty describes the proof-of-work target, not the hashrate of an individual ASIC. A higher value requires more expected hashing work for a valid block. It does not increase a miner's rated terahashes per second, electrical power or firmware clock by the same percentage.
The network does not directly measure every miner's physical equipment. Hashrate estimates are inferred from observed block production and can vary with the averaging window. A difficulty of 140.58 trillion should therefore not be labelled 140.58 trillion hashes per second or treated as a live inventory of machines.
How the retarget boundary works
Bitcoin Core's published proof-of-work code calculates the adjustment from timestamps in the preceding interval, subject to the protocol's bounds and target limit. The normal interval is 2016 blocks, designed around a ten-minute average block target rather than an exact appointment on a calendar.
The timestamp of the first block at the new difficulty identifies the event for this report. Subtracting it from the first block of the old epoch is not a substitute for reproducing the exact consensus calculation: the code uses the last block of the previous interval and its defined starting block.
The inverse matters to expected output
With fixed device hashrate, expected block-finding rate is inversely proportional to difficulty. Dividing the old difficulty by the new one gives approximately 0.9440759. Under unchanged assumptions, expected subsidy output per unit of time is therefore about 5.5924% lower, rather than 5.9237% lower.
For an explicitly hypothetical previous expectation of 0.001 BTC per day, the corresponding new expectation would be about 0.00094408 BTC per day. This is an arithmetic illustration, not a measured payout, a quote for a particular miner or a promise of regular solo-mining income.
Revenue is not net profit
A difficulty increase does not automatically change a device's electricity bill. If hashrate, watts and operating hours remain fixed, energy use remains fixed while expected coin output changes. Profit must then account separately for electricity, pool fees, maintenance and other costs.
The impact on profit can be proportionally larger or smaller than the output change and may move a marginal scenario into loss. It cannot be expressed as a universal 5.59% profit decline. Different tariffs, machine efficiencies and operating schedules produce different results even at the same network difficulty.
Subsidy, fees and price stay separate
This retarget is not a block-subsidy halving. The subsidy remains governed by the separate halving schedule; transaction fees can change the total reward of individual blocks. The calculation above deliberately isolates expected subsidy output rather than assuming every future block has the same fee income.
Dollar revenue also depends on Bitcoin's price. This report does not infer a current exchange rate, fee share or hashprice from the difficulty number alone. A rise or fall in coin price can offset or amplify the revenue effect without changing the physical performance of the ASIC.
Pool and solo outcomes differ
For pool mining, actual settlement depends on the pool's accounting method, accepted shares, fees and rejected or stale work. The idealized difficulty ratio does not establish a miner's next invoice or imply that all pools deliver identical day-by-day payouts.
For solo mining, the expected rate describes probability over repeated trials, not a daily payment. A small device can receive nothing for a long period despite operating correctly. A valid comparison should distinguish long-run expectation, realized reward and the device's displayed hashrate.
What operators should update
Use the realized difficulty in scenarios and keep the source timestamp alongside it. The next normal boundary is height 973728; a projected date or percentage for that future boundary remains an estimate. The earlier interval's result is a historical fact, not a guarantee about the next one.
The new difficulty does not justify adding an ASIC model or changing its stock specification. Catalogue hashrate and power remain device-specific, while network assumptions belong to the revenue calculation. Keeping these layers separate makes the calculator easier to audit and prevents a network event from becoming a fictitious hardware upgrade.
Source: Mempool.space ↗ · Mempool.space block API ↗ · Mempool.space block API ↗ · Bitcoin Core proof-of-work rules ↗
Mining calculator ↗
