What we are proposing
Today's rule, Knots #419, locks every block reward mined from block 973,440 until block 979,920, about 45 days later, and then goes back to the usual 100 blocks. Two open proposals would extend it. #429 holds those rewards until RDTS expires on September 1, 2027, up to a year. #434 releases them in four steps over the same year.
#467 is simpler: each reward unlocks 6,480 blocks (about 45 days) after it is mined, on a rolling basis, until RDTS expiry. Then the network decides what comes next (keep 45 days, move to a year, go back to 100, or adopt a dynamic rule) with about ten months of real data instead of a few weeks.
- No reward waits longer than the 45 days already in force. Block 979,920 can spend block 973,440's reward, exactly as today.
- From block 979,920 it only tightens #419, so it is a soft fork relative to today's rule, and it reuses RDTS's own expiry date.
- Like every proposal on the table, it has to ship before block 979,920, expected around the end of October.
The data
We classified every block since the XBT fork from its coinbase, the way reorg.watch labels templates, and checked the result against reorg.watch's own table: 138 against its 137 of the last 152 blocks, pool by pool.
In the week before the flag day, 28% of blocks came through DATUM pools. Most of the rest were templates built centrally by pools, including AlphaPool's own PPLNS pool, then 34% of blocks. Four weeks later, 91% of blocks come through DATUM pools, and blocks from pools' own template software are down from 28% to under 4%. Five of the six largest pools now build all of their blocks through DATUM, and the sixth builds more than half. All of this happened under a 45-day lock, the only lock that has actually been enforced.
Why this matters to XBT Long Term Holders
If you intend to participate in the XBT ecosystem, further the mission, and retain exposure for the long haul, these network behaviors have a potentially massive, long negative tail.
It tampers with issuance. The total supply does not change, but when newly mined coins can move does, and that is part of the monetary policy every holder relies on. Changing it this much, this fast, adds the kind of policy volatility sound money is supposed to be free of. Long after the year ends, it stays on the record for the protocol's entire history.
It tells people how they may move value. The premise of an open, permissionless protocol is that the transfer of value stays unadulterated. #419 describes the year as step two of three, and step three is to “withhold rewards for any blocks produced by non-miners”. If part of the reason for a year-long window is to keep that option open, deciding later by human judgment which already-mined coins may move, that sets a far more extreme precedent, and it flies directly in the face of decentralization.
“Under attack” is not a blank check. The 45-day lock was a proportionate response to a real concentration of hashrate, including on our own pool. That threat has largely passed. Escalating from 45 days to a year, with reward voiding on the table, on the same justification, is the playbook of governments and nation-states. It is exactly the kind of behavior Bitcoin was designed to resist.
Why 45 days rolling, not a one-year freeze
- It already works. The goal was blocks built by miners, not by pools. Under the 45-day lock, the DATUM pool share went from 28% to 91%.
- 45 days is a real deterrent. There are no 16-hour payouts: a miner pays for power and hosting for six weeks before the first coin can move, on top of running a node. Profit-only hashing does not survive that. Honest miners can.
- A freeze cannot tell honest miners apart. Consensus only sees the coinbase. DATUM miners paid directly in the coinbase are locked exactly like a pool's treasury. With 9 in 10 blocks already built through DATUM, a year-long freeze lands mostly on the miners doing it right.
- Nobody waits longer than the rule they mined under. Rewards mined since September 21 were mined under a 45-day lock. Re-locking them for up to a year deters nothing, because that hashing already happened. It only changes the deal after the fact.
- Evidence before permanence. Today's data covers a few weeks, gathered in response to a threat. RDTS expiry is a natural checkpoint: about ten months of data on hashrate, security and miner economics, then a deliberate decision about the long-term rule.
- It keeps the network together. A year-long freeze risks splitting miners and node runners again. A middle path keeps everyone on one chain.
- It is a small, well-tested change. It only tightens today's rule, reuses RDTS's expiry, and nodes that upgrade before block 979,920 skip any historical recheck. It was tested with warnings-as-errors builds, 35 focused unit cases, 27 functional runs across the expiry and upgrade paths, and 16 deliberately broken builds, all caught by the tests.
Claims for a one-year freeze, and why they don't hold
“If the 45-day lock lapses, miners go straight back to stratum.”
This is the main risk raised against letting #419 run out, and #467 answers it directly: the lock never lapses. It stays in force until RDTS expires, the same end date as #429, with no extra soft fork in between. Nothing about the deterrent goes away at block 979,920.
“The release notes said rewards would be locked for a year.”
The year was announced. The 45-day lock is what nodes enforce. #419 itself called 45 days a first step “to make sure side effects (expected or not) are tolerable”. The first step worked, and the rule should follow that evidence, not a plan written before any data existed.
“Anything shorter than a year defeats the point.”
If the point is that miners, not pools, build blocks, that has already happened under 45 days: 91% of blocks through DATUM pools, under 4% from pools' own template software. The bite comes in the first weeks, paying for power and a node with nothing to show for it. Past that point, extra months add cost for the miners already doing it right, not deterrence. That is also why six months and a year feel the same: both are well past the point where profit-only hashing gives up.
“A year is needed to stop stratum-to-pool ‘non-miners’, and to work out how to identify them.”
A coinbase lock cannot see how a template was built. A block from a DATUM gateway and one dictated by a stratum pool can be identical in shape, as Knots #421 lays out. The length of the lock does not change who it hits. It only changes how much it costs them. And the time to work on identification is the same ten months either way: under #467, every reward is still locked while that work happens.
“Hashers will just leave a DATUM pool for one that isn't.”
There is little left to leave for. Pools' own template software built under 4% of blocks in the latest week, and the lock applies to every block on the network, whichever pool found it.
What we are asking
If you mine XBT or run a node, read #467, test it, and say where you stand on the pull request, with data if you have it. Whatever the network chooses has to ship before block 979,920.
A good compromise leaves everyone a little unhappy. This one keeps a real deterrent, spares honest miners a year without income, and lets the data decide the long-term rule.
Disclosure: AlphaMine runs AlphaPool, a DATUM pool on XBT. Every rule discussed here applies to our blocks and our miners the same way it applies to everyone else.