How to read Bitcoin difficulty and retarget estimates
Separate current epoch progress, future timing estimates and source history. An explicit interval scenario shows how assumed block speed changes a projected date.
1. Block heights define the epoch
Bitcoin mainnet retargets difficulty every 2,016 blocks. The source supplies the next retarget height and remaining block count. Their difference identifies the height underlying this particular estimate; it is not another independently fetched chain tip. The epoch starts at the next boundary minus 2,016.
Progress is that height minus the epoch start, divided by 2,016. The first epoch block therefore has zero offset. We retain exact counts and denominator alongside the source percentage; no extra block is added to make the indicator appear fuller.
2. An estimated change is not confirmed difficulty
difficultyChange is the estimated percentage for the next change. previousRetarget describes the preceding change and stays separate from the forecast. The provider estimates future pace from block times, using a sliding window early in the epoch. Protocol adjustment bounds constrain the result, but future blocks and their times remain unknown.
The next retarget date is a provider estimate in Unix milliseconds. previousTime is instead the epoch start time in Unix seconds. Mean intervals and remaining duration are milliseconds. Response capture is a separate clock, neither a block timestamp nor independent node verification.
3. Your scenario uses an explicit assumption
Enter assumed seconds per future block, then apply the draft. Your projection multiplies remaining blocks by this interval and adds the duration to its explicitly stated anchor. It does not alter the provider estimate, network difficulty or original input. This is a simple timing alternative, not a probability or an exact forecast.
Editing a scenario reuses the same captured batch without another network read. A separate refresh obtains a new batch or the original fresh cache. Charts, tables, details and exports always correspond to the applied scenario and manifest.
4. History and hashrate retain their own scope
The monthly response has an independent capture. It contains current difficulty and a network hashrate estimate over the last 1,008 blocks; this is not a fixed calendar week. Original H/s are retained, while shortened EH/s are presentation only. A zero error fallback remains unknown.
Hashrate history retains source daily timestamps; the latest day may still evolve. This endpoint groups historical difficulty records by day and averages them, so they are not guaranteed unchanged individual block headers. Their adjustment is a multiplier: for example, 1.05 means approximately +5%, not +1.05%. Small differences from another estimate are never silently reconciled.
5. One analysis, two source contexts
The retarget view and monthly history have separate availability, capture, cache expiry and SHA-256. Failure in one part does not fill its values from another part or with zeros. Nearby capture times do not establish an atomic snapshot. Original age remains visible after cache expiry.
Complete JSON and CSV contain both normalized inputs, every historical row, your scenario and the manifest. A selected detail or current table never shortens them. A local result establishes neither public data rights, guaranteed mining income nor a future Bitcoin price.
This is a guide to Datisto. Private features require sign-in and access to your own data. Personal models use your assumptions; availability and permitted use of source data are checked with the particular result. This is not investment advice.