Pay by the clock

Bitcoin pays 3.125 XBT to whoever finds a block, and a block is a block whether it took ten minutes or thirty-one seconds. On September 1 this chain found 1,782 of them and paid 5,573 XBT, because hashrate had outrun a difficulty that recomputes every 2,016 blocks and cannot move more than four times a step. Three steps in a row hit that cap. The ten-day window in which a block cost a fraction of what it should have is the profit the mercenary hash came for, and post fourteen scored the proposals for closing it. This post works out a rule none of them contains: pay the subsidy by the clock instead of by the block. It is an explainer, not a proposal. We run one node and one miner, we do not run consensus code, and we do not vote.

The rule

A block’s reward is 3.125 XBT for every 600 seconds that passed since the previous block, instead of 3.125 XBT flat. A block found 31 seconds after the last one pays 0.16 XBT. A block found after 20 minutes pays 6.25. A day pays about 450 XBT however many blocks it holds, which is what bitcoin’s schedule intends: 144 blocks of ten minutes, 450 coins.

The clock is the header’s timestamp field, not any node’s clock, so the interval is a difference of two numbers every node already holds, the same way the retarget’s timespan is. Two details make it a rule rather than a slogan. The interval is measured between median times, not raw timestamps. Bitcoin already requires every block’s timestamp to exceed the median of the previous eleven, a rule in ContextualCheckBlockHeader in validation.cpp, and BIP 113 moved time locks onto that median in 2016 for the same reason this rule would: one miner cannot move a median with one header. And a single block’s reward is capped, here at four times the base, 12.5 XBT, so a stalled chain does not mint a jackpot for whoever finds the next block.

What it would have done

Every coinbase since activation, from our node, against the same blocks paid by the clock. Fees are under one percent of the reward and are the same on both sides.

By day, the chart on the card: September 1 paid 5,573 and would have paid 454; September 2, 5,047 against 461; September 7, 2,894 against 450. The 31-second epoch, which paid the same 6,301 XBT as every other epoch, pays 330. In fourteen and a half days the chain paid 32,200 XBT and would have paid 6,680. Every day since activation would have been within a few coins of 450, and one block in 10,298 would have hit the cap. Measuring with raw timestamps instead of medians changes the total by half a percent. The tool runs against a node’s own coinbase ledger, and the JSON it writes is what the card was drawn from.

Everything else about the window stays. Blocks still come in 31 seconds, difficulty still lags, and the fleet still arrives. What changes is what the window pays. The extraction event, as a number, is 25,000 coins above the schedule; under the clock it is zero, because there is no way to get more than a day’s coins out of a day.

What it does to the incentive to add hash

A miner’s share of the day is still its share of the hash. Adding hash still earns more, and the fight for share still happens. What disappears is the reason to bring hash for a window: profit per hash on a day is 450 XBT times the price divided by the network’s hash, and the retarget’s lag no longer enters that number. Hash arrives when the chain is worth mining at its steady rate and not before. Post fourteen’s test asks whether a rule changes the payoff or tries to identify the player. This one changes the payoff, for everyone, from the first block, and names nobody.

It also works the other way, which the cap on difficulty does not. If half the fleet left tomorrow, blocks would run 948 seconds and the next retarget would be 22 days away; if nine tenths left, 4,740 seconds and 110 days. Under the per-block subsidy the miners who stayed would be paid a third or a tenth of the schedule for months. Under the clock they are paid for the time, up to the cap, and the chain’s daily issuance holds through an exodus as it holds through a raid.

What breaks

Timestamps can be gamed, inside a box. A miner sets the timestamp in the header, and nothing checks it against a real clock. Two rules draw the box: the timestamp must exceed the median of the previous eleven, which lags real time by about six blocks, and it may not run more than two hours ahead of the network’s clock, the constant MAX_FUTURE_BLOCK_TIME in chain.h. Inside that band a miner can push a timestamp forward to fatten an interval. Measuring between medians blunts it: a block is paid for the time around six blocks earlier, and one header moves an eleven-block median by little or nothing. And any second a miner steals by pushing time forward is a second the next block cannot claim, so across blocks the lie is zero-sum except where it hits the cap. The retarget has a timestamp weakness of its own, the time-warp attack that BIP 54 is written to close, and a rule that pays by time inherits every timestamp problem the difficulty rule has.

Withholding pays. This is the real flaw, and it comes from the rule itself. A miner who finds a block 60 seconds after the last one earns 0.31 XBT by publishing it. Every second it sits on the block, the clock adds to its reward, and the only cost is the chance that someone else finds a block first. The arithmetic says holding is profitable at the margin for every block found earlier than the target, and it is most profitable for the miner with the most hash, because it can keep mining on its own withheld block. That is the selfish-mining shape with a reward attached, and a chain running this rule would have to measure it before anything else. Paying between medians shrinks the gain, since the withholder’s own timestamp barely moves the median, but it does not remove the incentive to delay the publication itself. A cap at the base, so a block can pay less than 3.125 and never more, removes the jackpot but not the marginal gain.

Hash switches inside the interval. A block’s reward under the clock is smallest right after the last block and grows every second. Hash that mines wherever the next block pays most leaves the moment a block lands and comes back as the reward climbs, so hashrate oscillates within every interval, not across epochs as Bitcoin Cash’s did in 2017. It is withholding without a block to withhold: the miner sits on its hash instead. Raised in the Knots Discord on September 14, after this post went up.

Security still needs difficulty. The clock fixes what the window pays; it does nothing about what the window costs to attack. A chain at 31-second blocks is as cheap to reorganize under this rule as under the old one. The retarget, or a faster one, is still the security rule, and this rule sits beside it, not in place of it.

The schedule changes unit. Bitcoin’s halvings are counted in blocks, 210,000 of them. Under the clock the halving has to be counted in seconds, or the 21 million cap no longer holds. A change to the schedule’s unit is the largest kind of consensus change there is, and it is a hard fork if any block can pay more than the old rule allowed. The version with the cap at the base, where a block can only ever pay less, is a strict tightening, and old nodes accept every block new nodes do. From our node, that version pays 6,275 XBT over the same fourteen days instead of 6,680, and 274 blocks hit the cap.

Has anyone done this

Not that we can find, and we looked. Kaspa’s Crescendo upgrade in May 2025 cut the per-block reward tenfold when it went from one block a second to ten, so that emission per second stayed where it was; the reward is still fixed per block and does not depend on the interval. Nervos CKB fixes the base issuance per epoch, an epoch targets about four hours, and the per-block reward is the epoch’s issuance divided by the number of blocks the difficulty rule put in it. That is the nearest cousin: emission per unit of time, enforced one epoch at a time. Grin’s sixty grin a block at a one-minute target is described as one grin a second and is paid per block. Zawy, whose difficulty algorithms run on dozens of small chains, lists “adjusting reward based on solvetime” among articles he planned and never wrote. We found no proof-of-work chain that reads the interval in the header and scales the coinbase to it. If one exists, the discussion link below is where to say so.

September 14. Within twelve hours a variant appeared that pays for share instead of timing: a seven-day epoch by median time past gets a fixed budget of 3,150 XBT, and after it closes every block in it gets an equal cut, settled 100 blocks later. Nothing to withhold, since delaying a block does not change the count, and no rich or lean blocks for switching hash to chase. It is written up as an issue on Zawy’s difficulty-algorithms repository, with its own open questions. We sent its author five points the same morning: the payout delay is the maturity lock’s economics in a milder dose; how one block’s share splits across a multi-output coinbase is undefined; removing any block from an epoch raises everyone’s cut a little; the surge still happens as a fight for a fixed pie; and the wait is a sawtooth across the epoch. By 12:20 UTC the issue was at revision 2 with all five folded in and credited to this site. A block’s coinbase output values are now the settlement weights. The claim that difficulty drops out of revenue is withdrawn: share is counted in blocks, and a hash-hour before the retarget steps up finds more of them than one after, so the surge still wins share, diluting itself as it goes. The orphan term is written down, with the author’s argument that a per-block subsidy carries the same term through the retarget, lagged instead of immediate. The author’s lean moved to a one-day epoch, and a new section scores the rule against Knots #405: the pull request fixes spacing, the epoch budget fixes allocation. Still a first pass, on both sides.

September 15. Zawy replied on the issue at 22:43 UTC: “It’s nice and simple and I don’t remember someone proposing it before… If it works as good as I think it does, it largely solves what me and many other spent years on (which is on/off attacks),” with his own prescription for the clock and the difficulty rule: monotonic timestamps so raw header time can replace the median, an exponential moving average with N = 288, a future-time limit of 60 seconds, no peer time, no 4x clamps. The same evening we posted a second note, on the settlement mechanism rather than the incentives, checked against the Knots source at the running release: the settlement block can be made impossible, since a coinbase may carry about 6,400 distinct payout scripts under the 800,000-weight cap and two such blocks would need a settlement that cannot fit; settlement outputs count as weights as written, so each epoch’s payees would take the settlement block’s own share; and one timestamp sits inside eleven medians, so the boundary moves by several blocks, not one, which Zawy’s monotonic timestamps would fix. The idea stands; the mechanism needs a bound. Our own numbers on seven-day against one-day epochs are in Pay for share.

September 16. The withholding math, done properly, and it corrects this post twice. A solved block’s reward cannot grow while it waits, because the timestamp is under the proof of work; what pays is dating the header a block-time ahead, holding it if it solves early, and dropping it if someone else lands first. Under the raw form of the rule, with no cap, a miner with one percent of the hash gains 10 percent over honest mining that way, one with a fifth gains 8, one with three quarters gains 2.5: the smallest miner gains the most in percent and the largest the most in coins, the opposite of what the withholding paragraph above says. The closed form came out of a model review we commissioned; our own simulation of the strategy matches it. Under this post’s version, intervals between medians and a cap at four times the base, the calculation is different and not done. Zawy’s own take the same morning, on the issue: a timestamp-proportional reward would not get accepted, the problem being how to enforce accurate timestamps; his enforcement, a 10-second future-time limit, does not touch the strategy above, because a held block is first seen at its own timestamp. Our reply with the table is there too, with a second comment on the settlement from our node. The share rule’s timing weakness sits at the epoch boundary and is worth a fraction of a coin; this rule’s sits in every block.

September 17. The calculation the line above left undone. Under this post’s own version, intervals between medians and a cap at four times the base, the pre-dating strategy loses at every share and every deadline: 22 percent at a fifth of the hash with a deadline of one block-time, and 1.5 to 6 percent at the best deadline it can pick. The fattened interval is paid to whoever mines the next several blocks, so at a fifth of the hash the honest miners’ share rises from 80 to 84.4. The chain’s real intervals give the same numbers within a point, and the cap makes no difference; the median does. Letting the miner keep mining on top of its held block turns the strategy into selfish mining, which pays only above a third of the hash and, between medians, pays exactly what it pays under bitcoin’s rule. If everyone runs the pre-dating strategy under the raw rule, shares break even and the difficulty rule collapses, since every interval is then at least the deadline and the rule keeps lowering difficulty to chase a mean it cannot reach. What the median leaves is the two-hour limit: a miner that stamps every header two hours ahead drags the median past real time once it holds about a third of the hash at a ten-minute pace, or a fifth at this chain’s 31-second pace, and Zawy’s monotonic stamps with a 60-second limit remove that too. Our comment with the tables is on the issue.

And a correction to “Has anyone done this,” the kind the closing paragraph asked for. A proof-of-work chain has run a form of this rule. Qwertycoin, a CryptoNote coin with a two-minute target, proposed in May 2019 to multiply the block reward by the interval since the previous block over the target (issue 78), merged the code that July, and activated it at block 700,000 in 2020 under the name EPoW: linear below the target, the fourth root of the ratio above it, capped at twice the base, the two-hour future-time limit left as it was. Zawy argued against it in that thread in February 2020, offered a bounded symmetric version, and described the strategy above in words, six years before the closed form: a large miner sets every timestamp to the target and holds the block until that time arrives. So the sentence that he listed the idea and never wrote it is wrong as well. He wrote it, as a comment, and against. What that chain’s timestamps show after block 700,000 we have not looked at.

What is on the table instead

Bitcoin Knots PR #405 (the PR and its author’s GitHub account both returned 404 by September 18; the description here is from the code as it read on September 11), opened September 11, is the closest idea in code. While active, a block must beat its target divided by a factor that is 1 while the last 72 blocks’ hashrate sits within five quarters of the 4,320-block trend and rises to 8 as hashrate departs upward. It is a fast difficulty adjustment with a sunset, a strict tightening, and it changes what a surge costs. The clock changes what a surge pays. Both take the profit out of the window without asking who is in it. The difference is where the money goes: under #405 the surge still pays 3.125 a block but finds fewer blocks; under the clock the surge finds every block it can and each one pays less. Neither one is on a start date, and neither is this post.

What we would watch, if any of it moved: the withholding arithmetic, measured rather than argued; whether the maturity proposals and a rate rule are being scored on the same test; and the day the retargets get boring, which is the day none of this matters.

This is a first pass, from one node, by people who do not write consensus code. We could not find this rule built anywhere or worked through anywhere, and we would rather be corrected than credited. If you know where it was tried, if you can do the withholding math properly, or if you can break it in a way this post missed, 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.