The mercenary hash problem

The people who run this chain are picking a number this week. Bitcoin Knots pull request #402, opened September 10 at 18:32 UTC by Chris Guida, would make every newly mined block reward unspendable for 26,280 blocks instead of 100, as a temporary rule that expires with the rest of the RDTS deployment on September 1, 2027. It has no start date, and the poll on how long the lock should be is still open. This post does not argue for a number. It says what the problem is, where it came from, and offers one test, Satoshi’s own, to score each proposed fix by. The test has an opinion about the number. What follows is the test, not a vote.

What happened

The chain activated on August 30 at a difficulty a few CPUs could match, paying 3.125 XBT a block. Hashrate followed the profit. Blocks ran 31 seconds on September 1, and difficulty could not catch up, because of a rule bitcoin has carried since 2009. Difficulty is recomputed every 2,016 blocks from how long the last 2,016 took, and one recomputation cannot move it more than four times up or four times down. On bitcoin that cap guards against a bad clock or a run of luck, because hashrate cannot quadruple in two weeks. Here it did, several times over, and the cap bound three retargets in a row, on September 2, 4 and 8, each exactly four times the last. Post seven has the table. The window in which a block cost a fraction of what it should have stayed open ten days instead of one.

Someone was going to take that window, and one pool took most of it. Our node reads the payout address on every block. It counted AlphaPool above half the blocks, 54 percent, in the day and a half before its operator promised on September 7 to “cap AlphaPool at 30% of the knots network hashrate, permanently”, and 37 percent of the 786 blocks since, through September 10 at 20:17 UTC. We post the count as it moves. The pool speaks Stratum v1, and that detail matters more than the percentage, for a reason that comes next.

The responses, in order. A deadline. A pull request to make the pool’s payout address unspendable by consensus, opened September 7, which Luke Dashjr answered the same evening with “This is not safe to run in its current form.” A post from Luke on September 10 floating two temporary rules, a month-long lock on newly mined coins or a month of no block subsidy, aimed at “a large batch of hashers who appear to only have profit as their motive.” The subsidy idea, rejected by the room within the day. And PR #402, the lock, at six months.

Three harms, not one

The word in use is “attack”, and it is carrying three different things with three different fixes.

Concentration. Anyone with half the hashrate can reorganize recent blocks and censor transactions, and the risk is real from about a third. Anyone with a node can measure it. Nobody can attribute it: the chain sees a payout address, not an operator.

Template control. A block template is the list of transactions a miner is hashing. Under Stratum v1, the protocol most pool software speaks, the pool builds the template and sends the miner a job, so the miner’s hash votes for whatever the pool put in the block. Under DATUM, which several pools on this chain support, the miner’s own node builds the template and the pool only splits the pay. A chain whose reason to exist is a rule about what goes in blocks has, to the extent it mines through Stratum v1, handed the enforcement of that rule to whoever runs the biggest pool. This is why a 37 percent Stratum v1 pool is a liability and 37 percent of hash on miners’ own templates would be security. Same hardware, different owner of the vote.

Extraction. Hash that arrives for the profit window, sells every coin the day it can, and leaves. The subsidy goes out, the coins land on a market that is a week old, and whoever holds the coin carries the sell pressure. A block reward cannot be spent until 100 more blocks have been mined on top of it, a rule called coinbase maturity, and on this chain 100 blocks has taken between one and six hours.

The first harm is measurable but not attributable. The second is structural, and fixable at the pool layer without a rule. The third is an incentive, and it is the only one of the three that a consensus rule can reach without identifying anyone.

The problem has a name

The Byzantine Generals’ Problem is the wrong ancestor. Satoshi’s November 2008 email called the proof-of-work chain “a solution to the Byzantine Generals’ Problem”, meaning agreement among parties who do not trust each other, and this chain agrees on its blocks fine. The question here is who the generals are and whether they can be hired away. That is an older problem, and it has a name.

Machiavelli, The Prince, chapter XII, in W. K. Marriott’s 1908 translation: “Mercenaries and auxiliaries are useless and dangerous; and if one holds his state based on these arms, he will stand neither firm nor safe; for they are disunited, ambitious, and without discipline, unfaithful, valiant before friends, cowardly before enemies; they have neither the fear of God nor fidelity to men, and destruction is deferred only so long as the attack is; for in peace one is robbed by them, and in war by the enemy. The fact is, they have no other attraction or reason for keeping the field than a trifle of stipend, which is not sufficient to make them willing to die for you.” A page later: “The mercenary captains are either capable men or they are not; if they are, you cannot trust them, because they always aspire to their own greatness.”

Five hundred years old, and it reads like this week’s timeline.

So: the mercenary hash problem. Hash that is hired by the block reward and has no other reason to keep the field. Two smaller ideas travel with the name.

The Sybil problem. John Douceur’s 2002 paper The Sybil Attack showed that “without a logically centralized authority, Sybil attacks are always possible”: one party can present as any number of parties. A pool is a Sybil by construction. The chain sees addresses and coinbase tags, and an operator can have as many of either as he likes. Luke said it plainly on September 10: “There’s no way to identify pools on the tech side, only the human side.”

Goodhart’s law. When a measure becomes a target, it stops being a good measure. Share of blocks by payout address measures a pool well today and measures nothing the day a cap is enforced on it, because a second address costs one line of config.

The Satoshi test

Section 6 of the white paper: “The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.”

He did not detect dishonesty. He priced it. That gives a one-line test for any proposal: does it change the payoff, or does it try to identify the player? Bitcoin’s own history has run the test twice.

Pool hopping, 2011. Miners jumped between pools that paid proportionally per round, mining the early, overpaid part of each round and leaving. Meni Rosenfeld’s Analysis of Bitcoin Pooled Mining Reward Systems worked through it and described the fix: pay-per-last-N-shares, which “does away with the concept of ‘rounds’” and so “removes the concept of profiting by mining ‘early in the round’”. Nobody was identified. The payoff was changed and the behavior stopped.

GHash.io, 2014. One pool held more than half of bitcoin’s hashrate for most of a day on June 12 and 13, and on July 16 pledged not to exceed 39.99 percent. No rule was written; miners left and the share fell. Pressure worked because the operator had a name and wanted to stay in business. It is the one precedent for the deadline approach, and it worked once.

The test also has something to say about the cap. Bitcoin’s four-times cap bound exactly once in bitcoin’s own life: block 68,544, July 16, 2010, five days after the Slashdot article that brought the first GPUs. Satoshi predicted it that morning: “I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.” It did, from 45.38, and in the fifteen years since, no adjustment has exceeded two times. The rule was written for a chain whose hashrate cannot move fast enough to matter, and its one exception was bitcoin’s own bootstrap. This chain is a bootstrap. The cap bound three times running and held the profit window open for ten days, and that window is what the mercenaries came for. Nobody built the honeypot on purpose. A rule for a mature chain ran on a newborn one.

The proposals, scored

Each one: what it changes, how it is gamed, and the test.

Do nothing and let difficulty work. The window is the lure. Once difficulty catches hashrate, profit per hash falls to what the marginal honest miner will accept, and rented hash is indifferent between this chain and the next. It is happening: blocks came in from 31 seconds to about 200, and the fifth retarget, September 12 at block 971,712, was the first the cap did not touch: 2.99x, to eight-minute blocks at the hashrate that produced it. The one cost is that the cap also limits the fall: if the mercenaries leave together, blocks slow for days. Test: passes. It is the design.

A pool cap by consensus rule. “No pool above 30 percent.” The chain cannot see a pool; it sees addresses, and a cap on addresses is beaten by a second address, a proxy pool, a “different” operator. The only enforcement that works is a whitelist of approved pools, which is the thing this chain forked to get away from. Test: fails. It is identification.

Make the operator’s address unspendable (PR #396). Same failure, plus the address changes in one line of config, and because the rule was written to apply retroactively, a node that syncs from scratch under it forks off at the first block that paid the address. Worth keeping as a precedent: the chain declined to write a person into consensus.

A longer coinbase maturity (PR #402). A block reward becomes a forward position in the coin. The mercenary’s payoff no longer depends on today’s price and today’s difficulty; it depends on the price when the lock ends and on financing the power bill until then. Hash-and-dash needs the dash, and this removes it. It names nobody, applies to every block equally, and expires on a date already in the code. Guida’s answer to the supply objection is right on the facts: “the maturity rules don’t affect the supply, they just affect when new coins can be spent.” Test: passes. Among the live proposals it is the only one that does.

The number is the argument, and the number is in blocks. The code says 26,280, which is six months at ten-minute blocks. This chain has not yet had a window at ten minutes. At tonight’s 223 seconds a block, 26,280 blocks is 68 days; the PR body says “could be as little as 2 months depending on hashrate”, and the first review comment makes the same point: “26280 is six months only at 600s, so the realized delay drifts with difficulty while the boundaries don’t.” The poll is being taken in days. The code, as opened, does not contain days. At 20:27 UTC Guida replied that he would make a second branch that counts time instead of blocks, “and we can have both on the table.”

Who it hurts, in order: the small miner paying a monthly power bill from block rewards, most; the mercenary with cheap capital, less; the miner who was going to hold anyway, not at all. That is the reverse of the order the rule intends, and it is why the length matters.

What it sets in motion:

1. Pools float the payout. A pool with a treasury pays its miners today and holds the locked rewards itself. Miners go to whichever pool can do that, and the pool that can float six months of payouts is the best-capitalized one. A rule written to break a big pool hands the biggest pool a new reason to exist. The shorter the lock, the smaller the treasury it takes to float it.
2. A forward market appears. Locked rewards get sold over the counter as IOUs, or an exchange lists them. Legitimate, and it makes the lock a discount rather than a barrier, paid to whoever has capital. Same winner as point 1.
3. The lock shrinks to nothing at the end. The rule expires with RDTS and everything unlocks at the expiry, so a reward mined in the last week of the window waits a week. The other review comment says so; Guida answered that it “was intentional, but it’s certainly still open for discussion.” Whatever the number, the last stretch of the window is unguarded, and everything locked inside it unlocks on one known date.
4. Governance risk gets priced. Every consensus change made under pressure raises the return an outside miner requires before pointing hardware here, and it compounds with each use. A temporary rule with a date is the cheapest form of this. It is not free.
5. The reflex. Once maturity is the lever, the next raid gets a longer lock rather than a better protocol. The rule should carry its own sunset argument: it buys time for difficulty and for DATUM to do the permanent work, and it has failed if it is still being extended when RDTS expires.

Zero subsidy for a month. Fees-only pays almost nothing on a chain with an empty mempool. Rented hash leaves the hour it activates, honest hash follows the day after, and with the cap on the way down difficulty takes weeks to find what is left. Test: passes on the letter, since it changes the payoff for everyone, and fails on the consequence, because it removes the honest miner’s incentive along with the mercenary’s. The room got there in a day.

DATUM, by pool fee. Template control is the harm that makes concentration dangerous, and DATUM removes it: a pool’s share becomes a payout statistic rather than a vote. It cannot be a consensus rule; a block is a block, and the chain cannot tell whose node built the template. It can be a price. Lazarus Pool said on September 9 it would proxy Stratum v1 hash to other pools above 25 percent of the network and add “a 3% fee to ONLY lazy stratum hashers, 1% of which will be going to my DATUM gateway contributors”, and turned the proxy on that night. That is a pool paying its own miners to take back the vote. If every DATUM pool taxes Stratum v1, the Stratum hash migrates to whichever pool does not, and that pool is the one to watch. Cat and mouse again, at a layer where losing a round costs a fee, not a fork. Test: right target, wrong tool as a rule, right tool as a market.

Deadlines and names. GHash.io shows this works once, against an operator who has a name and wants to stay in business. The second operator will not have one. Test: identification, by definition.

Change the proof of work again. Matthew Kratter called it “the ultimate threat” on September 10, and its whole value is as a threat. Using it burns the hardware base the chain spent August building and tells every miner the chain will do it a third time. The mercenaries lose nothing; they rent the next algorithm too.

Faster difficulty. The small proof-of-work chains met rented hash years ago. Bitcoin Gold lost about 18 million dollars to double spends in May 2018 to hash that arrived for the attack and left. The chains that survived converged on one defense, a difficulty rule that adjusts every block over a short window: Zawy’s LWMA, published December 2017, is the common one, and Bitcoin Gold is on its list of adopters. The profit window that attracts a raid closes in hours instead of days. This chain kept bitcoin’s 2,016-block window and four-times cap unchanged, and the bootstrap is the one condition they were not built for. A shorter window while hashrate finds its level, or a cap that steps down as the chain matures, attacks the harm at its source. The objection is cultural, since it is the part of the code bitcoin people least like to touch, and it is the scenario the room has not discussed. Test: passes. It is the incentive, not the identity.

Cat and mouse, run forward

Two rows end somewhere good, and they are the same idea: shrink the prize, and the game is not worth playing. Every row that tries to find the player ends in a list of approved players.

What good looks like

Five conditions, each checkable.

1. The template belongs to the miner. A pool’s share is a payout statistic, not a vote. Measure: the fraction of blocks built on the finder’s own node. Today it is a minority.
2. Difficulty tracks hashrate within hours. There is no window to raid. Measure: the ratio between a window’s pace and the pace it was set for. For three windows it was four, capped.
3. Mining profit sits near the cost of honest capacity. The market does this; the chain’s job is to stop delaying it.
4. Rules change rarely, by announced deployments with dates, and expire. PR #402’s shape, a flag day and an expiry, is the right shape whatever its number.
5. The chain does not try to enforce what it cannot see. No operator’s address in consensus. Hostility toward mercenaries comes from arithmetic, and people stay out of it.

Under those five, decentralized mining is not a rule anybody wrote. It is what is left when there is nothing to game.

What the test says about the number

The test does not pick a number. It says which direction to lean and why. A lock long enough that no mercenary will finance the power bill for it does the work against the dash, and a few weeks of ten-minute blocks is long by that measure. Every additional month past that point buys little against extraction and costs more on the other side: a bigger treasury advantage for the biggest pool, a deeper discount on forward-sold rewards, a larger pile that unlocks on one date, and a longer time for a rule made under pressure to sit on the chain’s record. The Satoshi test favors the shorter number.

It also says to argue the number in the unit the code counts. As opened, that is blocks, and blocks on this chain are not ten minutes yet; the days are an estimate that depends on who shows up.

As of September 10 at 20:30 UTC, PR #402 has no mainnet start time. If one is set, the date goes on the front page and here.

September 11. The time-based branch exists: PR #403, “MTP variant of #402”, opened 21:43 UTC September 10. And #402 changed its number overnight: at 01:59 UTC September 11 the constant became 6,480 blocks, with a note on the PR, “Changed 6 months to 45 days based on community polls.” In the unit the code counts, 6,480 blocks is 45 days at ten minutes; at the 164 seconds the last 200 blocks averaged on September 11, it is about 12 days. Neither PR has a start time. A third proposal, PR #405, takes the other row of the table: while active, a block must beat its target divided by a factor that rises, up to 8, when short-window hashrate departs upward from the long-window trend. That one changes the payoff of a surge rather than the spending of its reward. Untested, unreviewed, and noted here because it is the first code that answers the test’s question directly.

September 15. The receipt. Mining Stacker, whose September 13 video prompted Who got the coins, closed his two weeks on the chain with a results video that reads that post on screen and then opens his books (from 8:31): “realized profits… actual bitcoin,” 0.58 BTC from renting his hash out, “about 44,000,” another “16,000” from selling mined coins on the exchange, “a grand total of about 65,000 dollars,” against “seventy-seven hundred dollars invested total on hardware” and “about 450 dollars in electric costs,” with “90, 95 percent of that… made that first week.” On the lock: “the money was already made… it can go to zero tomorrow and it doesn’t matter.” On the cause: “most modern proof of work coins know this and they have much faster block adjustment periods.” That is the third harm, counted by the man who took it. Two-thirds of it was paid in bitcoin by whoever rented his hash, which no rule on this chain reaches; the rest, by his account, was sold before the number was picked.

September 18. The start time exists, and it is not #402 or #403. On September 15 at 04:50 UTC Luke Dashjr opened PR #419, “Long coinbase maturity (part 1 of 3)”, his own branch: coins mined from block 971,712 on wait 45 days, enforced from 973,728, the same block as the next retarget, and released at 980,784. The release notes say the community “has decided to extend” maturity “up to 350 days, and possibly make it contingent on actually mining,” that this release “deploys only a 45-day maturity time, but nothing more,” and that anyone mining “without running DATUM Gateway yourself” should “expect to never get paid any rewards for that going forward,” with “updates around October 15th and 2027 August 1st.” Three reviewers have filed bugs; it is not merged and there is no release as of 20:30 UTC. Scored against the test: the number is the short one, in days rather than blocks, and the notice is the part the test could not see coming, a rule announced before it is written. The date goes on the front page too. Separately, PR #405 and its author’s GitHub account both return 404 as of today; the description above is from the code as it read on September 11.

September 19. The heights moved. Luke rebased #419 at 01:55 UTC, “adapted to strict 45-day window, with no restriction on pre-enforcement coins”: start and enforcement are both block 973,440 now, about September 21 at the current pace, release is 979,920, and coins mined before 973,440 are not touched, so the lock no longer lands on the retarget block. The release notes now say “up to 350 days,” that non-DATUM hash should “expect to never get paid,” and to plan for updates “around the end of October and 2027 August.” Scored against the test, nothing changes: the number is still the short one and the notice is still the part that matters. Not merged as of 11:30 UTC.

September 20. The release candidates exist. Luke tagged 29.4.2rc1 on September 19 at 15:04 UTC and rc2 on September 20 at 04:30 UTC, signed, with binaries for every platform on the Knots file server, and both set 973,440 and 979,920 for mainnet. Our status post on September 19 at 18:53 UTC said no release carried #419; rc1 had been public since 15:04. The pull request is still open and there is no final release as of 21:30 UTC; the six commits pushed to it tonight are the revalidation framework and release notes that rc2 already ships, and rc2’s own notes say “mid-October” where the pull request says “the end of October.” Reviewers are running rc2 against the branch’s functional tests and two of their own: the pruned-node retry case passes, and the one failure needs an assumeutxo snapshot above the window, which no release ships, so it does not reach this deployment. Two things read from the rc2 source that the heights do not say. Consensus leaves coins mined before 973,440 alone, as Luke wrote on the 19th. Policy does not: the mempool applies the 6,480-block maturity to every coinbase from height zero, by design (the commit: “so policy always requires the long maturity for generated coins”), and the wallet reads the same number, so a miner who upgrades to rc2 sees any coinbase younger than 6,480 blocks as immature and that node refuses to relay a spend of it, while nodes on 29.4.1 relay and mine the same spend; on that version the policy outlives 979,920. And every coin mined inside the window matures at 979,920 and none earlier, because the rule switches off at that height: a coin from 973,440 needs exactly 6,480 blocks, and a coin from 979,000 is freed by the switch-off, not by its count. The chain is at 973,265 as of 21:29 UTC; 973,440 is about September 21 at 17:00 UTC at the last day’s pace of 397 seconds a block.

September 21. #419 merged at 05:40 UTC and the final, 29.4.2.knots20260508, was published at 06:02 UTC. Its code is rc2’s plus seeds and documentation, so both readings above stand, and its notes say to plan for updates “around mid-October and 2027 August.” Our node moved from rc4 to it at 10:50 UTC, at block 973,375: 22 seconds down, wallet loaded, and getdeploymentinfo now lists long_coinbase_maturity as a flag day at 973,440, last enforced height 979,919, maturity 6,480, not yet active. The chain is at 973,377 as of 10:54 UTC; 973,440 is about 18:00 UTC at today’s pace of 434 seconds a block. The upgrade post has the steps, dated.

September 21, 18:00 UTC. The rule is active. @BitcoinKnots announced the final at 11:09 UTC and Luke wrote at 11:17, “this afternoon instead of tomorrow, upgrade ASAP.” Block 973,440 came at 17:49:53 UTC, coinbase tag CrypticBro2009, 3.12665716 XBT to one output: the first coin under the 45-day wait, spendable at 979,920 and not before. Our node, on 29.4.2 since 10:50, reports long_coinbase_maturity active as of 973,442 at 17:58 UTC. Chris Guida posted “in 2 blocks” at 17:37, Luke “Time’s up, softfork is active” at 17:51 and, at 18:01, that the old 100-block maturity is a grace period. It is: a coin from 973,440 cannot be spent in any block before 973,540, so a miner still on 29.4.1 cannot make a block that 29.4.2 rejects until then, about September 22 at 06:00 UTC at the window’s 449 seconds a block.

September 26. A correction to the cap paragraph above. We replayed the surge from our node with the four-times cap removed and the rest of the rule unchanged. It still pays 20,555 of the 26,112 XBT. The cap’s share was 5,556 XBT, about a fifth. The first two windows, 11,153 XBT, were paid before the cap first bound at 965,664. The rest came from the window itself. A window is 2,016 blocks, and at 31-second blocks that is 17 hours. When hash doubles inside a window, the window pays about a thousand extra blocks with or without the cap. When it triples, about 1,350. So the cap held the profit window open longer, and the window rule paid four fifths of the surge on its own. Delete the part has the run, in both directions.

Discuss this post on X

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