What it takes to mine the BLAKE2b chain, before there is one.

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 15 August 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 13 August, 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 21 August 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 21 August 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 19 August, but the block header is still being reshaped, with support for multiple ASIC profiles landing as recently as 22 August, and nobody has run real silicon against the final construction on a live network. Anyone stating flatly that a given box will or will not work on activation day is still ahead of the evidence.

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 8 August, 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.

The RDTS chain has reached 961,637 as of 22 August. It is crawling rather than stopped: one block arrived on 17 August and one on 21 August, each after days of nothing, which is what mainnet difficulty does to a chain with a sliver of the hashpower. The majority-hashpower chain is past 963,600 and adds roughly 144 blocks a day. Five blocks against two thousand and counting is the number to sit with, and it is the honest starting point for anything else on this site.

There is a September 1 date, and it is a target, not a schedule. Luke Dashjr gave it himself on 11 August, answering a mining pool asking whether to start mining BLAKE2b immediately: "Target is Sep 1. Need to write and properly test the code first... Until it's ready, SHA2 continues on."

Read the second half as carefully as the first. The date is conditioned on finished, tested code, and that condition is now visibly being worked: the pull request left draft on 19 August, signed release candidates were tagged on 21 and 22 August, and the first public trial ran on testnet4 the night of 21 August. What still does not exist is a mainnet activation height. The code deploys by block height, not by calendar date; testnet4 has its height set, and the mainnet field carries the annotation "set at release cut," meaning the height gets chosen only when the final release ships.

Chris Guida, who assembled the proof-of-work code, wrote on 4 August 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 19 August: 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.