SHA-256d

Bitcoin Knots is attempting a second major fork of Bitcoin using BLAKE2b proof-of-work after its previous BIP-110 chain collapsed after just two blocks, raising fundamental questions about whether the project can secure sufficient mining hardware and economic support to remain viable. The Sunday test will reveal whether the alternative consensus mechanism can produce blocks at all, but institutional investors face the core uncertainty of whether any exchange, custodian, or infrastructure provider has committed to supporting the breakaway network.

• Bitcoin Knots will test a BLAKE2b proof-of-work fork on Aug. 30, replacing SHA-256d entirely after activation
• The previous BIP-110 fork died after producing only two blocks three weeks earlier due to miner defection
• As of Aug. 29, no major exchange, wallet, custodian, or Lightning implementation had publicly committed to the new chain

• 2 blocks Before the BIP-110 fork stalled compared to continuous chain production
• 870 TH/s Required hash rate versus 50-70 TH/s measured testnet capacity available
• Aug. 30 Scheduled test date for BLAKE2b consensus mechanism activation rehearsal

Bitcoin developer Luke Dashjr is orchestrating a controlled test of Bitcoin Knots’ new fork architecture on Aug. 30, with a final release planned for Sept. 1 if the rehearsal succeeds.

The attempt represents a fundamental shift in strategy from the failed BIP-110 chain, which relied on existing Bitcoin miners to voluntarily produce blocks on a minority network before a silent miner boycott halted production after just two blocks.

The new proposal permanently abandons SHA-256d altogether, instead requiring specialized BLAKE2b hardware that includes repurposed Sia mining equipment such as Bitmain’s Antminer A3 and Goldshell SC5 models.

The timing reflects urgency tempered by incomplete preparation. Dashjr instructed SHA-2 miners to cease mining before the Aug. 30 test, which will establish the final SHA-256d block before activation of the new consensus rules. Bitcoin Knots 29.4.1rc4 is meant to serve as the transition point, with the release candidate already in circulation as of late August.

However, the public Bitcoin Knots release page had not yet displayed rc4 or a completed 29.4.1 build as of Aug. 29, and several core proof-of-work parameters remained unfinalized at that point.

BIP-110 fork died after two blocks due to miner defection despite initial enthusiasm

The earlier BIP-110 attempt provides a cautionary template for the BLAKE2b proposal. When BIP-110 split from the dominant Bitcoin chain roughly three weeks before the Aug. 30 test, it initially attracted enough mining attention to produce blocks. Yet the fork stalled almost immediately after, producing only two blocks total before a coordinated miner boycott halted further production.

The failure exposed a critical vulnerability in the fork’s design: it depended entirely on voluntary participation from miners already committed to SHA-256d hardware and to securing the main Bitcoin chain.

That dependency proved fatal. Miners faced a direct choice between committing hash rate to the minority fork or the majority chain where block rewards held established value. Without an independent mining constituency or hardware locked into the fork, BLAKE2b’s designers argue the new approach eliminates this incentive misalignment.

By requiring purpose-built hardware incompatible with Bitcoin’s existing SHA-256d infrastructure, the breakaway chain would theoretically prevent defection: miners either dedicate Sia-compatible equipment to the fork or they cannot participate at all.

The theory remains untested at scale. A code reviewer calculated that maintaining 10-minute block intervals on the new network would require approximately 870 terahashes per second of sustained hash rate. Measured testnet4 capacity from available compatible hardware was estimated at only 50 to 70 TH/s, a gap of more than ten-fold.

Those figures derive from incomplete code and do not represent final launch parameters, yet they illustrate the arithmetic problem: having access to compatible machines does not guarantee that operators will actually deploy them to the fork.

No major infrastructure provider has publicly committed support before the test

Sunday’s rehearsal will measure whether BLAKE2b blocks can be produced at all, but that technical success would not resolve the institutional viability question facing the fork. As of late August, Bitcoin Knots had not publicly identified any major exchange, wallet provider, custodian, blockchain explorer, or Lightning Network implementation committed to supporting the breakaway chain.

This absence matters because a fork cannot achieve economic viability without infrastructure willing to list it, custody it, or route payments through it.

The lack of public commitment creates a chicken-and-egg problem for the fork’s backers. Infrastructure providers typically wait to see evidence of user demand and mining security before investing in support. Yet users and miners typically wait to see infrastructure support before treating a fork as economically viable.

A successful BLAKE2b block on Aug. 30 would prove the technical mechanism works, addressing one source of uncertainty. It would not demonstrate that enough hash rate exists, that enough users are willing to hold the new asset, or that the economics justify support from custodians and exchanges.

Dashjr and his collaborators have published testnet4 mining instructions and a DATUM Gateway fork compatible with the new proof-of-work system, creating a foundation for miners to begin testing participation. The existence of these tools lowers the technical barrier for testing participation.

However, tools and actual deployed hash rate remain separate phenomena, and the public record as of the test date contained no disclosures of pledged mining capacity from major operators.

Consensus rules remain incomplete ahead of Sunday’s activation test

Beyond mining and infrastructure, the fork still lacks final consensus rule specification as of the eve of the Aug. 30 rehearsal. While the core innovation involves replacing SHA-256d with BLAKE2b, Bitcoin forks require precise specification of difficulty adjustment algorithms, block size limits, signature validation rules, and other technical parameters.

Unfinalized code on key proof-of-work changes meant that even the technical rehearsal carried uncertainty about what exactly was being tested.

The incomplete specification raises the possibility that Sunday’s test produces unexpected behavior requiring additional fixes. If the rehearsal fails, Dashjr indicated that Bitcoin Knots would issue another release candidate and reset mining to the last SHA-256d block. This would delay the Sept. 1 final release target.

The cycle could repeat multiple times if fundamental issues emerge during testing, extending the timeline for actual mainnet activation.

For institutional investors, the incomplete specification also underscores the distinction between a technical proof-of-concept and a production-ready network. Even if Aug. 30 succeeds in producing BLAKE2b blocks, the consensus rules would still need to be finalized, tested further, and reviewed by independent developers before exchanges and custodians could reasonably support the asset.

That review process typically requires weeks or months.

The success or failure of Sunday’s BLAKE2b test will determine whether Bitcoin Knots moves toward a Sept. 1 release or requires additional iteration. However, the test alone cannot answer the core institutional question: whether any major mining operator has committed to dedicating BLAKE2b-capable hardware to the fork, and whether any exchange or custodian plans to list or custody the resulting asset. The public disclosure of pledged mining capacity and infrastructure commitments, or the silence continuing past Sept. 1, will be the real indicator of whether this fork survives longer than the two blocks that killed BIP-110.