The one-part fix

Between August 30 and September 17 this chain paid 34,500 XBT in subsidy. Bitcoin’s schedule, 144 blocks of ten minutes a day, would have paid 8,388. The difference, 26,112 XBT, is the surge: hashrate arrived thirty times faster than a difficulty rule that recomputes every 2,016 blocks and cannot move more than four times a step could follow, and for ten days a block cost a fraction of what it should have. Pay by the clock and Pay for share worked out two rules that change what such a window pays. Both are patches on the retarget’s lag. This post asks the question underneath them: how much of the excess would a faster difficulty rule have removed by itself, with no new parts at all, and what would be left for a reward rule to do. The answer comes from replaying the chain’s real hashrate from our node. It is an explainer, not a proposal. We run one node and one miner, we do not write consensus code, and we do not vote.

The replay

Every block in our ledger, 11,040 of them from activation to 972,679, carries its difficulty and its timestamp, so the work behind it is known. The hashrate at any real moment is the work of the last 72 blocks over the time they took, held until the next block lands. That is the estimator the extra-work proposal uses for its fast window, and the window barely matters: 36, 72 and 144 blocks give the same answer within a tenth of a percent. Each rule then grows its own chain from the fork’s reset difficulty, 30,393,776, with blocks arriving at their expected times for the hashrate present, honest timestamps at the true time, and the rule setting the next difficulty from the chain it built. The first window reaches back to the pre-fork block 961,632 of August 8, which is why the real first retarget fell 41 percent and why the replay’s does too.

The check, before any result: fed the real timestamps, bitcoin’s rule reproduces all five retargets on the front page to the last digit, and fed the estimated hashrate it finds 11,035 blocks against the chain’s 11,040. One thing the replay does not model, and it cuts one way. Hashrate is taken as it arrived, whatever the rule. A fast rule would have made the window less profitable, so less hash would have come, so a fast rule’s number is the most it could have paid, not the least.

What each rule removes

Fees are 20 XBT over the whole period and identical under every rule, so the table is subsidy only. The moving average is zawy12’s rule for Bitcoin Cash from 2020, in the form he prescribed for this chain on September 15: the target moves every block toward the last solvetime with a memory of 288 blocks, which at ten-minute blocks is a half-life of 33 hours, and there is no clamp. Under a difficulty rule every block still pays 3.125 XBT. The only lever is how many blocks the hash finds.

A fast difficulty rule alone removes five sixths of the excess. What it leaves is the first two days. The average has a two-day memory and the hash arrived thirty-fold in less than that, so the replay pays 248, 326 and 329 blocks on August 30, 31 and September 1 before difficulty catches the hash, against 144 a day on the schedule and 332, 743 and 1,782 as the chain actually ran. From September 2 on the fast rule holds the chain within a few blocks of the schedule through the whole ramp. That residue, 1,433 blocks and 4,477 XBT, is what a reward rule would still have to do, and the clock and share rules remove it by construction, at the price of the new parts the two earlier posts spent their “What breaks” sections on.

Why the extra-work factor removes almost nothing here

Knots PR #405, opened September 11, read the same 72-block window against a 4,320-block trend and, while the fast rate ran more than five quarters above the slow one, divided the target by a factor that rose to 8. Its author’s own simulation was a one-week burst in a sixty-day run, hash that comes and goes. On that case the factor bites. On this ledger the hash did not leave; it grew for two weeks, and three things happen in order. The cap binds, so the burst is held to an eighth of its pace: 107, 92 and 178 blocks a day through September 1. With blocks held back, the first 2,016-block window takes until September 5 and still starts at the August 8 stamp, so the header retarget sees a 28-day span and halves the difficulty, where the real chain’s 22-day window cut it 41 percent. Then, as the ramp persists, the slow trend catches the fast window, the factor relaxes toward 1, and the low header difficulty pays out everything the factor held: 1,337, 1,286, 2,275 and 1,397 blocks on September 6 to 9, against 577, 926, 409 and 360 real. The excess is delayed, not removed. Starting the factor after the first, second or third retarget instead of at the fork moves the total by two or three points either way. That is the rule as it read on September 11; the PR and its author’s GitHub account both returned 404 by September 18.

What a fast rule costs

A difficulty rule that reads the last solvetime gives the timestamp more leverage than one that reads 2,016 of them, and that is the known price. The replay measures it the way the clock post’s September 17 line measured the reward rule’s: one actor with a share of the hash dates every header ahead by the future-time limit, honest miners stamp the true time, and every stamp is at least one second past the median of the previous eleven, so the actor’s stamps can drag honest ones. A difficulty rule sets one target for everyone, so who finds a block cannot move. What a stamp can move is how many blocks the chain makes in the same real time, and the actor’s take is his share of that change. Twenty seeded runs each.

Under bitcoin’s rule the forward stamps do nothing. Under the moving average a fifth of the hash stamping two hours ahead makes the chain 6.5 percent slower: the dragged honest stamps land one second past the median, the rule reads tiny solvetimes and raises difficulty, and the actor loses blocks too, his share of a smaller total. So the naive lever is not a gain under a fast rule. It is a cost to the chain’s pace, paid by everyone including the actor. Under a 60-second limit it is noise, which is why zawy12’s prescription for this chain pairs the average with a 60-second future-time limit and monotonic timestamps, no peer time, no clamps. Not measured: a majority actor, which his issue 36 covers and which is a different question from the one here, and an adaptive actor who stamps ahead only after a long honest gap. No orphan model.

The field that ran this argument first

Electric utilities in the United States have been priced by regulators since the 1900s, and the thing being regulated there is a lag. A utility’s rates are set at a rate case and stay fixed until the next one, and the gap between cases is called regulatory lag. The standard history, Karl McDermott’s for the Edison Electric Institute (2012), records that economists read the lag as an incentive, “similar to competition,” since a utility that cuts costs between cases keeps the difference. Then the October 1973 embargo sent fuel prices up faster than any rate case could follow, and regulators expanded a device that had existed since the First World War: the fuel adjustment clause, which “adjusted rates at regular intervals to reflect actual costs incurred.” The Federal Power Commission’s stated reason was to pass through changes in fuel cost “by eliminating ‘regulatory lag.’” The critics said the automatic clause undermined the very incentive the lag had provided, and the settlement was a three-part test for what may bypass the lag: a cost that is large, volatile, and outside management’s control. Alongside it sits the true-up, “an appropriate retroactive method” that reconciles what was charged against what turned out to be owed.

The map is close enough to use. The 2,016-block retarget is the rate case: fixed prices between reviews, and a lag that pays whoever moves faster than the review. The moving average is the adjustment clause: the same price rule, on a shorter cycle, for an input that is large, volatile and outside anyone’s control, which describes this chain’s hashrate exactly. The clock and share rules are the true-up: a retroactive settlement that pays out what the period was owed regardless of what the price rule did. Utility regulation reached for the adjustment clause first and the true-up second, and its critics spent forty years on what each one does to incentives. The one lesson this post takes from them is the order.

Where it sits today

The next retarget lands at block 973,728, around September 23, and the step is about 1.3x. The same block now carries a second rule: on September 15 Luke Dashjr opened Knots PR #419, a temporary soft fork that holds coins mined from 971,712 on for 45 days, enforced from 973,728, with a full year and withheld rewards for hash not run through the miner’s own DATUM Gateway “being considered” in its release notes. It is not merged as of this writing. Update, September 19: the PR was rebased overnight and the lock now starts and enforces at block 973,440, about September 21, with release at 979,920 and nothing before 973,440 touched; post fourteen carries the dated detail. Scored on this post’s table, a maturity lock changes nothing: the excess stays at 26,112, since the lock moves when a coin can be spent and not how many are minted. Post fourteen scores it on the other test.

None of the four rules in the table is on a start date, and neither is this post. The tool that made it, daa-replay.py, runs against a node’s own coinbase ledger and is the same one that reproduced the five retargets. What we would watch: the sixth retarget, which is the first the replay can check against a rule it did not fit; and whether the maturity lock, the fast rule and the reward rules ever get scored on one table by the people who write the code.

This is a first pass, from one node, by people who do not write consensus code. If the replay is wrong, if a fast rule has a cost this post missed, or if you know a chain that ran the adjustment clause and paid for it, the discussion link below is the place, and the next version of this post will carry what you found with your name on it.

Discuss this post on X

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