mempool.guide, 1 September, 16:34 UTC. The estimate is not a forecast. It is the ceiling.
The first retarget landed at block 963,648 at 16:33 UTC: difficulty went from 30,393,776 to 17,842,860, down 41.3%, for the reason in the correction to the three-blocks post. The projection there was 17.8 million and the chain delivered it to within 250. That part is over. The next part is the one worth writing down before it happens.
The cap
Bitcoin’s difficulty adjustment has had a governor on it since 2009: whatever the last 2016 blocks measured, one adjustment cannot move difficulty more than 4x up or 4x down. The window that just opened, 963,648 to 965,663, is the first one measured entirely under BLAKE2b. At about 2 PH/s and a difficulty of 17.8 million, a block takes about 38 seconds and 2016 of them take about 21 hours, against a target of 14 days. That ratio is 0.06. The code will want to multiply difficulty by 16 and will be allowed to multiply it by 4.
Then the same thing happens again. Here is the ladder, one row per retarget. Actual rows are what the chain did. Projected rows are our guess at hashrate, written out so it can be argued with, and recomputed at each retarget until a row reads ten minutes. The 1 September version of this table assumed a constant 2 PH/s and put 71.4 M at 965,664, then about 279 M and ten-minute blocks at 967,680, around 6 September.
| Date (UTC) | Status | Block | Hashrate | Difficulty | Change | Block time |
|---|---|---|---|---|---|---|
| 1 Sep 16:33 | actual | 963,648 | 1.3 PH/s | 17,842,860 | -41% | 31 s |
| 2 Sep 10:05 | actual | 965,664 | 2.45 PH/s | 71,371,438 | x4.0, capped | ~1.8 min |
| ~4 Sep | projected | 967,680 | ~3.2 PH/s | ~285 M | x4.0, capped | ~6 min |
| ~13 Sep | projected | 969,696 | ~3.8 PH/s | ~490 M | x1.7 | ~9 min |
| ~25 Sep | projected | 971,712 | ~4.4 PH/s | ~575 M | x1.2 | ~9 min |
Hashrate in an actual row is the average over the window that ended at that block; block time in the newest actual row is the pace of the window now running. Projected rows assume hashrate keeps growing: 30% over the window now running, then 20% and 15%. Faster growth means higher difficulty and slightly quicker blocks. Last update 2 September.
2 September. The second retarget landed at 10:05 UTC, four hours ahead of the 1 September estimate, because the window ran 31 seconds a block: about 2.45 PH/s against the 2 PH/s assumed. Difficulty is 71,371,438, exactly four times 17,842,860. The cap bound. Hashrate doubled daily through 1 September as gear people already owned came online, and has grown far more slowly since; the projected rows assume it keeps growing, fast now and tapering, and they stop where blocks are about ten minutes. Blocks sit a little under ten minutes for as long as hashrate grows, because each retarget is set from the window just finished.
What it means if you have one box
The odds per hash never change. What changes is how many hashes a block costs, and it is about to cost 4x more twice in three days. A box that has a fair chance of a block today has a fair chance of one this week at the second step, and of one this month at the third. This is the compressed version of what every Bitcoin miner lived through across 2010 and 2011, run at 300 times the speed, on a chain young enough that a single living-room box still shows up on the pools chart.
Why a cap at all
Because a single bad window should not be able to break the chain. A three-week stall, a clock game, an exchange dumping hashrate: any of those, measured honestly, would swing difficulty by a factor that no honest chain could survive the next period. The cap turns one violent correction into several gentle ones. The cost is what you are watching now: when the change is real, recovery takes several periods instead of one. The three-week stall that made the first retarget go down was the cap’s downside; the two capped rises ahead are its point.
We will put the actual numbers next to the projected ones as each block lands, on the front page and here.