What is actually known about the BLAKE2b proof-of-work chain and what the hardware really does. Sources over summaries. No advice, no affiliate links, nothing for sale. Check it yourself → Longer pieces on the blog; between updates, @BLAKE2bMiner on X.
New here? Start with The producers can leave, the post this site grew out of.
"A Peer-to-Peer Electronic Cash System, if you can keep it."1
The change
Blake2bHeight = 961640 for mainnet; Luke Dashjr called this run a "rehearsal." rc5, tagged September 1 at 00:56 UTC with signed binaries by 03:00, adds a checkpoint at 961,640 and hardcodes the headline, so there is no reset (Chris Guida, September 1, 04:12 UTC: "It's officially accepted as of rc5"); The final release, 29.4.1.knots20260508, shipped September 2 at 19:02 UTC, announced by @BitcoinKnots at 19:32; it keeps this chain, and its release notes put the consensus changes in one list: BLAKE2b, the unified opt-in sighash, RDTS at the flag day, a temporary 800 kWU block weight limit. As of September 23, 11:30 UTC the chain is at 973,786, read from our own node, on 29.4.2 since September 21, 10:50 UTC (rc4 from August 30 until then) and validating the BLAKE2b chain itself since August 30, 18:20 UTC. The first difficulty retarget came at block 963,648, mined September 1 at 16:33 UTC: difficulty fell 41.3%, from 30,393,776 to 17,842,860, for the reason given here. The second, at block 965,664, mined September 2 at 10:05 UTC, was the first measured entirely under BLAKE2b: the window ran at 31 seconds a block and difficulty rose to 71,371,438, exactly 4x, the most one adjustment allows, as projected here. The third, at block 967,680, mined September 4 at 16:46 UTC, was capped again: the window ran 97.5 seconds a block, about 3.1 PH/s, and difficulty rose to 285,485,753, exactly 4x. The fourth, at block 969,696, mined September 8 at 01:46 UTC, was capped a third time: hashrate tripled inside the window, from 3.6 to about 18 PH/s, the window ran 144 seconds a block, and difficulty rose to 1,141,943,013, exactly 4x. The fifth, at block 971,712, mined September 12 at 18:04 UTC, was the first the cap did not touch: the window ran 201 seconds a block, 24 PH/s on average and about 31 at the end, and difficulty rose 2.99x to 3,417,233,412. The sixth, at block 973,728, mined September 23 at 02:28 UTC, was the second the cap did not touch: the window ran 443 seconds a block, about 33 PH/s, and difficulty rose 1.353x to 4,625,039,957. At the pace since the step, 545 seconds a block over the first 57, the seventh, at 975,744, lands about October 5 at about 1.1x. A second rule lands just before it: on September 15 Luke Dashjr opened Knots PR #419, a temporary soft fork that lengthens coinbase maturity from 100 blocks to 45 days. As rebased on September 19 at 01:55 UTC it applies to coins mined from 973,440 on, due around September 21, and releases them at 979,920; coins mined before 973,440 are not touched (the September 15 draft had started at 971,712 and enforced from 973,728). Its release notes now say the community "has decided" on up to 350 days, possibly contingent on mining through the miner's own DATUM Gateway, that this release deploys only the 45 days, that hash not run through its own gateway should "expect to never get paid," and to "plan for updates around the end of October and 2027 August." Signed release candidates followed: 29.4.2rc1, tagged September 19 at 15:04 UTC, and rc2, tagged September 20 at 04:30 UTC, both with binaries on the Knots file server and both setting 973,440 and 979,920 for mainnet. #419 merged September 21 at 05:40 UTC and the final, 29.4.2.knots20260508, was published at 06:02 UTC, binaries at bitcoinknots.org; its code is rc2's plus seeds and documentation, and its notes say to plan for updates "around mid-October and 2027 August." Our node has run it since 10:50 UTC, from block 973,375, so it enforces the rule from 973,440. The rule is active: block 973,440 was mined September 21 at 17:49 UTC, coinbase tag CrypticBro2009, 3.127 XBT, the first coin under the 45-day wait, spendable at 979,920; our node reports long_coinbase_maturity active as of 973,442. @BitcoinKnots announced the final at 11:09 UTC, Luke Dashjr at 11:17: "this afternoon instead of tomorrow, upgrade ASAP"; at 17:51, "Time's up, softfork is active," and at 18:01 that the old 100-block maturity is a grace period: no coin from the window can be spent in a block before 973,540, about September 22 at 06:00 UTC, so a miner still on 29.4.1 cannot make a block that 29.4.2 rejects until then. Block 973,540 came at 04:40 UTC September 22, and in the 24 hours after it our node rejected ten blocks, nine that day at heights 973,543 to 973,666 and a tenth, 973,739, at 04:26 UTC September 23, each for spending a coin mined at 973,440 or later (bad-txns-premature-spend-of-coinbase; the youngest coin in each block 102 to 130 deep), with coinbase tags TwentyOne.Life, Tyger DATUM rented (three), Lazarus DouPool (two), xbtpool.io, Lazarus DATUM User and Miningcore (two); none is on the chain, no coin from the window has moved, and the day's record is here. Two things read from the rc2 source, unchanged in the final, that the heights do not say. Consensus leaves coins mined before 973,440 alone, but a 29.4.2 node's own mempool and wallet apply the 6,480-block wait to every coinbase from height zero, so a miner who upgrades sees any coinbase younger than 6,480 blocks as immature in that wallet and that node will not relay a spend of it, while nodes on 29.4.1 relay and mine the same spend. And every coin mined inside the window becomes spendable at 979,920 and none before, because the rule switches off at that height. Our own box found three blocks on August 30 and 31: 961,994, 962,126 and 962,193, about 3.13 BTC each; the rc5 checkpoint rules out the reset that would have erased them, and the final release keeps that checkpoint.Worth separating two things that get conflated. BIP-110 itself is the Reduced Data Temporary Softfork (RDTS), a soft fork restricting arbitrary data storage. It says nothing about proof-of-work, and it was marked Closed in the BIP repository on August 9. The BLAKE2b swap is a separate contingency, written afterward, once BIP-110 had failed to reach miner support. Until August 30 the RDTS chain and the BLAKE2b chain were not the same thing; since block 961,640 they are one chain, and the history above is why this site kept them apart.
This is the part most coverage skips, so it goes near the top rather than the bottom.
BLAKE2b mining chips exist and are sold today. Goldshell's SC line is marketed on the "Blake2B-Sia" algorithm and has been mining Siacoin and ScPrime for years. Current units are rated in the tens of terahashes. A good desktop CPU on the same algorithm is roughly four to five orders of magnitude behind that. The gap is not hypothetical: Connor's Lab measured about 5 GH/s from an RTX 3090 on a Sia pool, sitting next to a plug-in Goldshell box that does a hundred times that, with the box beside it doing double again. His conclusion for CPUs was blunter still: non-viable from the start. That number is why this site launched as CPUMINERS and is not called that anymore.
And letting them in is an explicit design goal, not an accident. The draft implementation is Bitcoin Knots pull request #359, opened August 15 by Luke Dashjr. Its own description states that it "aims to be compatible with PoW hardware produced by several (6 IIRC) vendors." We read that PR directly rather than taking anyone's summary of it.
Luke has also said publicly, on August 13, that "support for BLAKE2b also allows BLAKE2b-Sia miners, since the latter is a strict subset of the former," adding "Disclaimer: Have not tested yet."
That untested claim now has a first test. Connor's Lab compiled the draft proof-of-work code into a regtest node, pointed stock-firmware Goldshell units at it, and watched them mine blocks the node accepted. No firmware modification involved. One vendor's boxes, pre-release code, a test network rather than a live one, so it is not activation-day proof, but it moves the author's expectation from untested to tested once, and it is a check anyone with the hardware can repeat. Repeating it no longer even means compiling anything: Paul Lamb now packages the same check as install-and-go regtest apps for StartOS and Umbrel, and a box that fails generates a diagnostic report that feeds compatibility fixes back into the DATUM and Knots code.
And the test has since left the lab. On August 21 Luke announced a trial run of the first release candidate on testnet4, Bitcoin's public test network, and said the plan is to repeat it for each release candidate. Connor's Lab pointed five stock-firmware Goldshell boxes at that trial and mined accepted BLAKE2b test blocks, at one point holding most of the test network's hashrate. Same hardware caveat as before, one vendor's boxes, but this round ran on signed release-candidate code on a public network anyone can join. And the hands-on count is now two: Bitcoin Mechanic says he independently plugged a miner into the new DATUM and Knots builds on August 21 and watched it submit valid BLAKE2b shares, his own hardware, same pre-release caveats.
So the honest position is narrower than "unresolved." The author expects existing Sia-class ASICs to work, and the regtest and testnet4 runs so far agree. The pull request left draft on August 19, but the block header is still being reshaped, with support for multiple ASIC profiles landing in the pull request on August 22, and nobody has run real silicon against the final construction on a live network. The review is happening in the open and is finding things: on August 24 a reviewer reported two bugs, one where a miner-set config value over 93 bytes silently stalls mining, one where the difficulty window can mix both algorithms if the fork height is not aligned. Both small, both with fixes proposed, both caught on testnet, which is what a testnet is for. Anyone stating flatly that a given box will or will not work on activation day is still ahead of the evidence. Activation settled it. On August 30 and 31 our own stock-firmware Goldshell SC Box mined three mainnet blocks, and the chain's first hours were mined by a dozen Sia-class operators.
There is a real argument for it. A young chain with almost no hashpower is cheap to attack, and an existing pool of BLAKE2b miners is the fastest defense available. It is also worth knowing that this exact lever has been pulled before, in both directions: Siacoin once hard-forked to an altered BLAKE2b specifically to permit one vendor's ASIC and exclude every other, which is what produced Sia Classic, Sia Prime and Hyperspace.
One more thing from that same thread, because it is the sort of detail that gets lost. A miner replied to Luke noting that a CPU-only algorithm with memory hardening was an available option and is not what got chosen, and raised FPGAs as the further risk. That is reprogrammable hardware sitting between a general-purpose CPU and a fixed-function ASIC, and it can be pointed at whatever algorithm a chain picks. It is a third category this site has not covered and should.
What survives honestly: the BLAKE2b ASIC fleet is tiny next to SHA-256, so everyone small is far better positioned than on Bitcoin today. That is a real difference. It is not the same claim as "ASICs are gone," and on current evidence that second claim looks like it will stay false on purpose. So this site's answer is the same as the hardware's: get the box everyone was invited to bring.
On August 8, at block 961,632, Roughnecks mined the first block signaling BIP-110. F2Pool then built on a block that RDTS nodes reject, and the two chains parted.
Block 961,639 turned out to be the last SHA-256d block on the RDTS chain. Between August 8 and 29 that chain crawled: one block on August 17, one on August 21, one on August 23, one on August 28 at 17:14 UTC with an OCEAN coinbase tag, each after days of nothing, which is what mainnet difficulty does to a chain with a sliver of the hashpower. Seven blocks against nearly three thousand on the majority-hashpower chain, which stood at 965,033 on September 1.
Then, on August 30 at 06:14 UTC, block 961,640 arrived under BLAKE2b. It was mined by SilentWave and its coinbase carries the headline string. By 08:17 UTC the chain stood at 961,653: fourteen blocks in two hours from SilentWave, PyBLOCK, Helios, PythonPool, TrueNorth, Connor's Lab and one solo miner, each block just under the new 800,000-weight-unit cap that rc4 applies while RDTS is active (about 300 kB). One caveat on the morning numbers: until 18:20 UTC our own node could not validate BLAKE2b blocks, so the early heights above came from mempool.guide. That changed on August 30 at 18:20 UTC: the node runs rc4, and heights on this page are read from it directly.
There is now a stated date, and the author hedged every line of it. On August 29 at 02:35 UTC Luke Dashjr posted: "PSA: Potential Bitcoin PoW change Sunday. SHA2 miners should stop mining Saturday." The plan as he laid it out: Knots 29.4.1rc4, due Saturday, August 29, sets the last SHA-256d block and is a "mainnet rehearsal"; BLAKE2b blocks start Sunday, August 30; if the final release ships on September 1 unchanged, the chain that began Sunday is kept, and if anything breaks, rc5 resets to the last SHA-256d block and it starts again. That is the same pattern the testnet4 trials followed, where rc3 abandoned rc2's chain. His own words for the odds: "If there's any issues (unlikely at this point)." rc4 was tagged on August 30 at 02:09 UTC. Its mainnet parameters, read from the source: activation at block 961,640, checkpoints at 961,632 (first BIP-110 block) and 961,639 (last SHA-256d block), and RDTS rules on every block until September 1, 2027. The "rehearsal" caveat narrowed on September 1, when rc5 kept the chain rather than resetting it; the final shipped September 2 (status above).
The activation block carried a newspaper headline, and that was a rule, not a flourish. Satoshi put a Times headline in the genesis block to prove it was not mined early. PR #359 turned that into consensus: an rc4 node would not start without -blake2b_headline set by hand (rc5 hardcodes it), the source calls it a "consensus-critical proof-of-time news headline," and the activation block's coinbase must contain the exact string or the block is rejected. Luke said he would post the string after the New York Post's Sunday edition went online, on X, nostr, the Knots Telegram and the Knots Discord, with the live discussion in the Discord. Nobody can mine the activation block before the paper exists, and everyone running a node has to type the same headline. The string went out on August 30 at 05:16 UTC: 8-30 NYPost Deride And Conquer. Fifty-eight minutes later block 961,640 carried it.
How the date got here. On August 11 Luke gave it as a target: "Target is Sep 1. Need to write and properly test the code first... Until it's ready, SHA2 continues on." The pull request left draft on August 19; signed release candidates were tagged on August 21, 22 and 27 and each was trialed on testnet4. On August 27 he told a node runner "You will need to update September 1st to stay on the chain," and on the pull request the next day, asked about a testnet retarget bug: "Not expecting this testnet to stick around that long." Then the August 29 post above. The code still deploys by block height, not by calendar date, and that height, 961,640, shipped in rc4.
Your light wallet cannot see the new chain yet, either. The BLAKE2b block header is 164 bytes. Electrum-protocol wallets such as Electrum and Sparrow fetch 80-byte headers from a server and check the proof-of-work themselves, so after activation they are blind to the new chain until the protocol is extended. Paul Lamb posted a draft of that extension on August 24, and by August 27 had both halves running: a patched electrs serving the 164-byte header and a patched Sparrow following the live testnet4 chain. Working, but in his forks. Since August 31 there are downloadable builds: Paul Lamb's Sparrow v2.5.5-blake2b.1 with electrs-pruned, and Kyle Santiago's Shrike v2.5.5-blake2b.10. Unaudited, and none tried here yet: this site reads the chain from its own node, which needs no wallet build to see it; the wallet post has the detail. A full node of your own does not have this problem, which is one more reason this site keeps saying run one.
Chris Guida, who assembled the proof-of-work code, wrote on August 4 that it is "just some code to have in our back pocket in case miners betray bitcoin, to activate at some point later," and that "no deadline for activation has been set, and none is required to be set unless miners actually betray bitcoin."
Read that date. It is four days before the split. The same post ends: "I don't expect this code to be needed at all. I expect the miners to simply do the right thing and activate bip110 smoothly." They did not. We quote it anyway, dated, because it is the clearest statement of intent anyone has given and because watching a prediction age is more useful than quietly dropping it.
There is now a third chain, and its explorer can fool you. A project calling itself Bitcoin Purity surfaced around August 19: an anonymously run modified node that keeps SHA-256d, makes the RDTS data rules permanent, and drops the difficulty so its small hashpower can actually find blocks. We compared hashes: its chain matches the RDTS chain block for block up to 961,636, then continues with its own blocks that no RDTS node accepts. So its explorer shows heights past 961,648 that look like the RDTS chain moving and are not. If you are checking our numbers, and you should, a height read from mempool.bitcoinpurity.org is the Purity chain's tip, not the RDTS tip.
Heights here are read from our own Bitcoin Knots node enforcing consensusrules=rdts, not copied from a third party. Public explorers running Bitcoin Core rules cannot show you the RDTS tip at all. Cross-check against the live sources, and tell us if we drift.
A place to find out what is true right now, and what it actually takes to mine it. Chain status read from our own node. Hardware numbers measured rather than repeated. Links to the people and repositories doing the real work.
It is not an advice site. Nothing here tells you what to buy or what to do. The author holds BLAKE2b-capable mining hardware bought speculatively in August, before activation, now mining on it, and says so on the disclosure page rather than pretending to a neutrality nobody in this fight has.
There is nothing for sale, no sponsor, no affiliate link and no newsletter funnel.
An ask, not a toll. If something here saved you an hour, or a bad buy, the site takes XBT at one address:
bc1qc86hfgk9ahy95wd4qgjdd7j54lapux46z5vgk4
XBT only, on the chain this site is about. It goes to the node, the clankers, and the power bill. No perks, no tiers, no list of names.
One email when there is something worth your time: the final release, a wallet you can actually download, real measured hardware numbers, or news that actually changes the picture. No newsletter, no countdown timers, nothing to buy.
We'll use it for exactly that and nothing else. How we handle it. For the longer pieces, the blog. For the interim stuff that doesn't earn an email, follow @BLAKE2bMiner.
1. After Benjamin Franklin, leaving the Constitutional Convention in 1787. Asked by Elizabeth Willing Powel what kind of government the delegates had produced, he answered: "A republic, if you can keep it." The exchange survives in James McHenry's diary. Constitution maps to whitepaper, republic maps to peer-to-peer electronic cash. The wording here mirrors the whitepaper's actual title rather than paraphrasing it. ↩