Two more fours

mempool.guide, September 1, 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 September 1 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 September 6.

Hashrate in an actual row is the average over the window that ended at that block. Block time is the pace of the window that starts at that block: measured where the window has finished, otherwise the pace at the hashrate seen at the end of the window just closed (18 PH/s at 969,696, twice the window’s average, because hashrate tripled inside it; 31 PH/s at 971,712 against a window average of 24). Projected rows hold that hashrate flat: it is the fleet already pointed at the chain, not a growth rate. Rented hash can leave as fast as it came; if it does, blocks slow until the next retarget. An uncapped retarget sets ten-minute blocks at the hashrate that produced it. Last update September 12.

September 12. The fifth retarget landed at 18:04 UTC: block 971,712, difficulty 3,417,233,412, 2.99 times 1,141,943,013. The first step the cap did not touch, as the September 11 update said it would be. The window ran 200.6 seconds a block, 24.4 PH/s on average, from about 18 PH/s at the start to 31 at the end (159 seconds a block over its last 200). At 31 PH/s and the new difficulty, blocks run about eight minutes; the first 35 blocks after the step came in at 412 seconds, so the fleet has not left yet. The next step, at 973,728 around September 23, is about 1.3x to roughly 4.3 billion if hashrate holds, and ten-minute blocks from there. Whether it holds is the question post fourteen asked: the same hardware now finds a third as many blocks as it did this morning.

September 11. Hashrate jumped again: 30 PH/s over the last 200 blocks, 164 seconds a block. With 1,515 of the window’s 2,016 blocks mined at an average of 212 seconds, the elapsed time is already past what a 4x step would need, so the fifth retarget cannot be capped whatever the last 500 blocks do. It lands about September 12, and the step is now about 2.9x, roughly 3.3 billion, if the pace holds.

September 9. Hashrate kept climbing after the retarget: 22 PH/s over the last 200 blocks, against the 18 the September 8 row assumed, and blocks are running 223 seconds. That pulls 971,712 forward to about September 13 and raises the step to about 2.6x, roughly 2.99 billion. The cap still does not bind. It would take a window averaging under 150 seconds a block, about 33 PH/s, to bind a fifth time.

September 8. The fourth retarget landed at 01:46 UTC: block 969,696, difficulty 1,141,943,013, exactly four times 285,485,753. The cap bound a third time, and the September 4 row had said it would not: it assumed 20% more hashrate and got five times more, from 3.6 PH/s at the start of the window to about 18 at the end, after the coin got a quoted price on September 5 and Sia-class machines followed it. The window averaged 144 seconds a block, 8.5 PH/s; the raw ratio was 4.2x, so the cap trimmed only a sliver. At 18 PH/s and the new difficulty, blocks run about five minutes, so the next step, at 971,712 around September 14, is about 2.2x to roughly 2.5 billion, and that one the cap should not touch. From there the projected rows hold hashrate flat, a guess about a fleet that arrived in four days and can leave in four.

September 4. The third retarget landed at 16:46 UTC: block 967,680, difficulty 285,485,753, exactly four times 71,371,438. The cap bound again, as the row said it would. The window ran 97.5 seconds a block, about 3.1 PH/s against the 3.2 projected. The raw ratio was 6.2x, so without the cap this step would have been half again as large. Next is 969,696, around September 12, and it should be the first step the cap does not touch: at 20% more hashrate the window runs about five and a half minutes a block, which calls for about 1.8x, to roughly 527 million. That is the row now marked projected.

mempool.guide, September 4, 16:47 UTC. The previous step hit the ceiling; the estimate for the next one is under it.

September 2. The second retarget landed at 10:05 UTC, four hours ahead of the September 1 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 September 1 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.

Discuss this post on X

Saved you an hour? Tip the node and the clankers.