Bitcoin Knots is organizing a Sunday rehearsal for a BLAKE2b fork, following the stall of its previous breakaway BIP-110 chain.
On Aug. 29, Bitcoin developer Luke Dashjr instructed SHA-2 miners to halt operations ahead of an Aug. 30 test aimed at swapping Bitcoin’s SHA-256d proof of work for BLAKE2b on the proposed breakaway network.
Dashjr noted that Bitcoin Knots 29.4.1rc4 will mine the final SHA-2 block prior to the transition. Should the test run smoothly, a definitive 29.4.1 release could lock in the new chain on Sept. 1. Conversely, any complications will spark another release candidate alongside a rollback to the most recent SHA-2 block.
This initiative arrives three weeks after the BIP-110 branch detached from the primary Bitcoin network and ground to a halt after mustering just two blocks. The fresh strategy aims to bypass any reliance on current Bitcoin miners by permanently migrating the breakaway network to BLAKE2b proof-of-work hardware.
Nonetheless, the weekend evaluation kicks off with several unanswered questions. As of Aug. 29, neither rc4 nor a finalized 29.4.1 build appeared on the public Bitcoin Knots release page, and vital proof-of-work modifications were still open.
Additionally, the initiative has not publicly disclosed any prominent exchange, wallet, custodian, block explorer, or Lightning network implementation that has pledged support for the new chain.
Consequently, generating a successful BLAKE2b block will simply demonstrate that the fork functions in practice. It will not prove that a sufficient cohort of miners, infrastructure operators, and users are ready to sustain its economic viability.
BLAKE2b tries to solve the miner problem
The core modification targets the vulnerability that crippled the preceding BIP-110 branch.
Rather than relying on the SHA-256d miners securing the primary Bitcoin blockchain to mint blocks for a minority fork, the new network will reject SHA-256d blocks post-activation and utilize BLAKE2b hardware instead.
Supporters point out that devices originally engineered to mine Sia—such as Bitmain’s Antminer A3 and Goldshell SC5 models—can support the alternative proof-of-work mechanism. Furthermore, testnet4 mining instructions and a compatible DATUM Gateway fork have already been released.
It remains uncertain whether miners will adopt the system in sufficient numbers.
One reviewer of the open-source code estimated that a potential initial difficulty setting would demand roughly 870 terahashes per second to preserve 10-minute block spacing, whereas measured testnet4 capacity hovered between 50 and 70 TH/s.
While those calculations relied on incomplete code and do not represent final launch metrics, they underscore the hurdle facing Sunday’s test: possessing compatible hardware does not guarantee active hash rate. Public discussions omitted any figures regarding the capacity pledged by operators to the mainnet fork.
As a result, block generation will serve as an immediate test of whether the new architecture successfully rectifies the flaws of BIP-110 rather than merely swapping one mining demographic for another.
The fork still needs final consensus rules
Bitcoin Knots must also finalize the precise rule set that participating nodes will enforce.
As of Aug. 29, the BLAKE2b integration and an associated reduced-data proposal remained open, and reviewed public records had yet to lock down the mainnet activation height.
A discrepancy also surfaced regarding the temporary block-weight ceiling.
While the project’s pull request and FAQ outlined a 700,000-weight-unit limit, a pinned source commit established the cap at 800,000. Nodes operating on differing thresholds could dispute block validity, making a stable rc4 configuration essential before users attempt to follow the same ledger.
While the transition to BLAKE2b is permanent, the reduced-data restrictions—including the lower block limit—are slated to sunset in 2027.
Sunday’s test should consequently bring clarity to the activation height, block cap, and remaining parameters needed to keep participating nodes synchronized on a single ledger.
A working chain still needs an economy
Even if miners successfully generate blocks under a unified rule set, the more formidable coordination hurdle lies outside the control of Bitcoin Knots.
The proposed fork alters the block header structure to a 164-byte BLAKE2b layout, whereas legacy Electrum-style clients anticipate Bitcoin’s traditional 80-byte SHA-256d headers.
This means light wallets, indexers, block explorers, and related infrastructure will likely require updates before they can process the new chain. Dashjr stated that light-client compatibility sits outside the purview of Bitcoin Knots.
The project’s FAQ advises exchanges to suspend deposits and withdrawals around the fork event and formally declare which chain they intend to support. Pre-existing Lightning channels would exist on the BLAKE2b chain as well, necessitating that both counterparties operate compatible software and recognize the identical ledger.
Additionally, both networks would inherit identical pre-fork transaction histories and coin balances.
This introduces replay vulnerabilities, as a transaction spending pre-fork funds could theoretically clear on both chains.
Bitcoin Knots has introduced a SIGHASH_UNIFIED signing mechanism to offer directional replay protection upon explicit selection, though it will not automatically safeguard every legacy wallet or transaction.
Furthermore, the switch to BLAKE2b alters only the proof-of-work mechanism. It leaves Bitcoin’s existing addresses, private keys, and transaction signatures untouched, meaning ownership keys are not rendered quantum-resistant.
The immediate question for the weekend is whether Bitcoin Knots can successfully launch and sustain a BLAKE2b chain where BIP-110 stumbled.
A much greater test will follow should it succeed: whether miners continue minting blocks and whether exchanges, wallets, custodians, and users ascribe enough economic value to the new ledger to keep it operational.
