Pay by the clock went up on September 14 with a flaw named in its own text: a rule that pays a block for the time since the last one pays for timing, and timing is something a miner can choose. Within twelve hours a variant arrived that pays for share instead, written up as an issue on Zawy’s difficulty-algorithms repository. This post is what our node says about it, what we sent its author, what Zawy said, and where it breaks. 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.
Two rules, side by side
His. Time is cut into epochs, seven days in the worked example, one day in the author’s current lean. Each epoch has a fixed budget: 3.125 XBT for every 600 seconds of it, 3,150 XBT for a week, 450 for a day. When the epoch closes, count the blocks in it and give each one an equal cut. A week with 1,000 blocks pays 3.15 each; a week with 20 blocks pays 157.5 each. The coins are not in the block’s own coinbase. They are minted 100 blocks after the epoch closes, in a settlement block, which pays every address that appeared in the epoch’s coinbases its share in one output.
Ours. Pay each block 3.125 XBT per 600 seconds since the previous block, capped at four times the base. Same budget over the same time, paid block by block as it happens.
The two agree on what a day pays and disagree on who chooses it. Under the clock, a block’s pay depends on its timestamp, which its miner wrote. Under the epoch, a block’s pay depends on how many blocks the epoch holds, which nobody chose. That is the whole case for the variant: there is nothing to withhold, because delaying a block does not change the count, and there are no rich or lean blocks for switching hash to chase, because every block in the epoch is worth the same.
What a settlement block is
Under bitcoin’s rule the coinbase is the mint: the block that finds the coins is the block that carries them. Under the epoch rule the coins are minted later, by a block that had nothing to do with finding them. The rule says which block that is, the hundredth after the epoch’s last, and what it must contain: one output for every distinct payout script that appeared in any coinbase of the epoch, each holding that script’s total share, and nothing else. A block at that height without exactly that set is invalid. Every node computes the set from the chain, so there is nothing to trust, and the settlement block’s own miner gets no say in it.
That design has a property worth stating plainly before the numbers: the settlement block is mandatory and its contents are dictated by earlier blocks. Whoever can shape the earlier blocks shapes what the settlement block must be. Hold that thought.
What it would have paid
From our node, ledger to block 972,418 on September 16, every coinbase since activation run through the rule with epochs counted from the activation block’s header time. Fees are the same under every rule and are included in every figure.
The daily epoch does what the author says: per UTC day it pays between 319 and 528 XBT, and September 1, the day of 31-second blocks, pays 454 by the clock and 454 by share against 5,573 as paid. The weekly epoch does not: per UTC day it pays between 163 and 859, because inside a week the fast days take a bigger cut of a fixed budget. The 31-second retarget window, 2,016 blocks in seventeen and a half hours, was paid 6,300 XBT in subsidy. Its time share is 329. Under weekly epochs it gets 967, under daily 499: 2.9 times and 1.5 times what the clock would have paid it. Share is counted in blocks, and a hash-hour on September 1 at a difficulty of 18 million found sixteen times the blocks of a hash-hour on September 5 at 285 million. A fixed budget stops the surge from minting extra coins. It does not stop the surge from winning share.
What the wait looks like on the actual chain: a block found in the first hour of a weekly epoch waited 7.0 to 7.5 days for its settlement block, 3,700 to 6,700 blocks at the pace the chain ran; a block in the last hour waited between three hours and half a day. Daily epochs cut that to 1.0 to 1.6 days. The settlement output then matures like any coinbase, another 100 blocks.
The five points
We sent the author five points on the morning of September 14, and by 12:20 UTC the issue was at revision 2 with all five folded in, credited to this site, his answer under each.
- The payout delay is the maturity lock’s economics in a milder dose. A block’s value is unknown for up to a week and paid 100 blocks after that; easiest for whoever can finance it. He agreed it is the real cost, said any advance paid at block time is a per-block subsidy in miniature, and moved his lean to a one-day epoch.
- Multi-output coinbases were undefined. DATUM pools here pay a dozen or more addresses in one coinbase. He adopted the fix as written: the block-time coinbase’s output values are the settlement weights, nominal values allowed, split pro rata at settlement.
- A small new reason to orphan a rival’s block. Removing any block from an epoch raises everyone else’s cut a little. He pushed back: the same redistribution exists under a per-block subsidy, delivered through the retarget, lagged instead of immediate. It went into the text as its own paragraph with that argument beside it.
- The surge still happens as a fight for a fixed pie. He withdrew revision 1’s claim that difficulty drops out of revenue, and wrote the retarget-lag paragraph the numbers above confirm.
- The wait is a sawtooth. A block in an epoch’s last hour is paid weeks before one in its first. He agreed, ranked it lowest, and listed a per-block forward window as an alternative he did not adopt.
Zawy’s reply
On September 15 at 22:43 UTC, Zawy, whose difficulty algorithms run on dozens of small chains, replied on the issue:
This looks like a good idea. 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)… And in hindsight, it is actually is the way rewards should have been done all along.
With it, his prescription for the clock the rule reads: monotonic timestamps, so each block’s timestamp exceeds its parent’s and the raw header time can replace the eleven-block median; a future-time limit of 60 seconds; no peer time; an exponential moving average difficulty rule with N = 288; no clamps. The difficulty rule is its own post. The timestamp half matters here, because the epoch boundary is the one place where a timestamp still decides pay.
Where the settlement breaks
Zawy’s endorsement is of the idea, and it is conditioned: “if the implementation doesn’t have any holes.” We ran the revision 2 text through a long model review and then checked what it found against the Knots source at the running release and against our ledger. Three findings survived that night and went on the issue at once; our node added three more the next day, and they are on the issue too. Here they are by weight, not by date.
The settlement block can be made impossible. Under the reduced-data rules in force until September 2027 a block may weigh 800,000 units, and the only rule on a coinbase’s outputs is that each script be 34 bytes or less. There is no limit on how many. A pay-to-witness-key-hash output weighs 124 units, so one coinbase can register about 6,400 distinct payout scripts and be a valid block. Two such blocks in one epoch register 12,900, and the settlement that must pay all of them needs 1.6 million weight units. It cannot exist. Every candidate for that height is invalid, and the chain stops 100 blocks past the boundary. The registrations cost nothing beyond two blocks’ work, since zero-value outputs are legal and the rule gives a zero-total coinbase an equal split anyway. No majority is needed.
Weight is not the only wall. A 34-byte script made of 28 bare multisig opcodes passes the size rule, is spendable by the client’s definition, and is charged 2,240 units of sigop cost per output under legacy counting. The block limit is 80,000. Two registration blocks carrying 18 such outputs each force a settlement of 36 outputs costing 80,640, on 6,192 weight units. A bound on weight alone is not a bound.
The honest chain presses on the same wall by itself. Every coinbase on this chain carries a zero-value OP_RETURN, the witness commitment, and the commitments are distinct in all but a handful of blocks. Rule 4 as written registers every distinct script, so the honest chain’s first weekly settlement would carry 6,446 of those outputs plus 686 payout scripts: 1,297,280 weight units, 162 percent of the cap. The first honest settlement fails before anyone hostile shows up. One sentence fixes it, unspendable outputs are not registrations, but it has to be written.
Two more, smaller. Settlement outputs are themselves weights as written, so each epoch’s payees take nearly the whole of the settlement block’s own share, forever; one sentence fixes that too. And the origin: the rule counts epochs from the median time of the activation block, and on this chain that median is August 12, eighteen days before the block, because the last ten SHA-256d blocks were spread over three weeks. Read literally, the first four BLAKE2b blocks fall into two weekly epochs of two blocks each and take 1,575 XBT apiece; with daily epochs and the rule’s carry-forward of empty epochs, the first five blocks take 7,650 XBT. Counting from the activation block’s own header time removes it.
What a bound looks like. The honest chain’s fanout is small: the busiest weekly epoch had 831 distinct payout scripts, 13 percent of a block by weight, and the busiest daily epoch 430; the largest single coinbase on record pays 155 addresses. A cap in the low thousands fits honest use. But a first-come cap is its own problem, since one block can fill every slot with zero-value outputs and lock later miners out of their pay. The bound has to sit on direct registrations, in outputs, weight and sigops, with some claim path for the overflow. That is consensus state the rule does not have yet, and it is where the design work is.
The boundary
Under the epoch rule the only timestamp that affects pay is the one that decides which epoch a block lands in, and the stake is real whenever adjacent epochs differ in count: on this chain, a block moved from one daily epoch into the next was worth up to 1.09 XBT to itself, against a cut of 1.3 to 2.4. Revision 2 says a miner can move one block. Under the eleven-block median a timestamp sits inside eleven consecutive medians, so one choice moves several blocks across, whoever mined them. Zawy’s monotonic timestamps with raw header time fix that, and we said so on the issue. What we said next needed a correction: with monotonic timestamps a block pushed forward drags every block found within the future-time limit across with it. At last week’s pace a two-hour limit reaches 16 blocks; a 60-second limit reaches a tenth of one. So the short limit is part of the fix, not a nicety. With it, the model puts the boundary’s worth at a few thousandths to a few hundredths of an XBT per attempt for a miner with a fifth of the hash, and two orders less again if a block’s epoch is decided by its parent’s time. Small, not zero.
The withholding math, and our own rule
The same review did what our first post asked for: the withholding math on pay by the clock, properly. It corrects that 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. Our own simulation matches the closed form. The smallest miner gains the most in percent and the largest the most in coins, the opposite of what our post said. Zawy’s take on the clock rule, on the issue the morning of September 16: “I do not think this would get accepted,” the problem being how to enforce accurate timestamps; his enforcement, a 10-second future-time limit, does not reach the strategy above, because a held block is first seen at its own timestamp.
That is the comparison in one line. Both rules are sensitive to timing somewhere. His pushed it to the epoch boundary, where it is worth a fraction of a coin. Ours has it in every block, worth eight percent.
What is open
His: the epoch length, seven days or one; a cap or no cap for a near-abandoned chain where one miner collects a whole epoch; the boundary by median or by raw time; settlement in a coinbase or in a separate mandated transaction; what the rule adds on top of a fast difficulty rule; and a per-block forward window as an alternative. Ours: the bound, sized and specified; the boundary under a short limit, measured rather than modeled; and the epoch’s own retarget-lag share, which the numbers above put at 2.9 times for a week and 1.5 for a day and which no epoch length removes. The rule fixes what a surge is paid. It does not fix what a surge wins.
Against #405
The author’s framing, which we share: Knots #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) changes what a surge costs, by demanding more work per block when hashrate departs upward; this rule changes what a surge pays. They are complements. His own reading of #405’s simulation is that extra-work leaves the burst at about 1.7 times its hash-proportional share, and that this rule takes it to 1.0 independent of any estimator. The second half needs the qualifier his retarget-lag paragraph already carries: it holds when difficulty is constant across the epoch, and on this chain it was not. #405 is a soft fork with a sunset. This is a hard fork that moves the halving from a height to a time. Neither is on a start date, and neither is this post.
This is a second pass, from one node, by people who do not write consensus code. The idea stands and Zawy says so; the settlement needs a bound before the rule can be specified, and the issue is where that work is. If you can break it further, or bound it cleanly, the issue is the place, and the next version of this post will carry what you found with your name on it.
Saved you an hour? Tip the node and the clankers.