Bitcoin Knots Prepares BLAKE2b Fork Test After BIP-110 Chain Collapse

Bitcoin Knots is scheduling a Sunday rehearsal for a BLAKE2b-based fork following the failure of its previous BIP-110 breakaway chain, which stalled after producing only two blocks.

On August 29, Bitcoin developer Luke Dashjr instructed SHA-2 miners to cease mining ahead of an August 30 test that would replace Bitcoin’s SHA-256d proof-of-work algorithm with BLAKE2b on the proposed separate network.

Dashjr stated that Bitcoin Knots version 29.4.1rc4 would establish the final SHA-2 block before the transition. If the rehearsal succeeds, a final 29.4.1 release could preserve the new chain on September 1. Any problems would trigger another release candidate and a reset to the last SHA-2 block.

The attempt comes three weeks after BIP-110 split from the dominant Bitcoin chain and halted almost immediately. The new proposal aims to avoid another dependence on existing Bitcoin miners by permanently moving the breakaway network to hardware utilizing BLAKE2b proof of work.

However, several questions remain unresolved as the weekend test approaches. As of August 29, the public Bitcoin Knots release page did not display release candidate 4 or a final 29.4.1 build, while key proof-of-work changes remained open. The proposal had also not publicly identified a major exchange, wallet provider, custodian, block explorer, or Lightning Network implementation committed to supporting the new chain.

A successful BLAKE2b block would demonstrate that the fork can operate technically. It would not, however, establish that sufficient miners, infrastructure providers, and users are prepared to sustain it economically.

BLAKE2b Addresses the Miner Dependency Problem

The central change targets the weakness that crippled the earlier BIP-110 branch. Instead of relying on SHA-256d miners securing Bitcoin to continue producing blocks for a minority fork, the new chain would reject SHA-256d blocks after activation and depend on BLAKE2b-compatible hardware.

Proponents note that machines originally built to mine Siacoin, including Bitmain’s Antminer A3 and Goldshell SC5 models, can support the new proof-of-work system. Testnet4 mining instructions and a compatible DATUM Gateway fork have also been published.

Whether enough miners will actually participate remains uncertain. A reviewer of the open implementation calculated that one version of the proposed initial difficulty would require roughly 870 terahashes per second to maintain 10-minute block intervals. Measured Testnet4 capacity was estimated at only 50 to 70 TH/s.

Those figures were based on unfinished code and are not final launch parameters. They do, however, expose the core challenge facing Sunday’s test: compatible mining machines do not guarantee committed hash rate. The public discussion did not disclose how much capacity operators had pledged to the mainnet fork.

That makes block production one of the first measures of whether the new design has improved on BIP-110 rather than simply replacing one mining constituency with another.

Final Consensus Rules Remain Unsettled

Bitcoin Knots must also finalize exactly which rules participating nodes will enforce. The BLAKE2b implementation and a related reduced-data proposal were still open as of August 29, while reviewed public materials had not yet fixed the mainnet activation height.

A discrepancy also existed over the temporary block-weight limit. The proposal’s FAQ and pull request described a 700,000-weight-unit cap, while a pinned source commit set the limit at 800,000. Nodes enforcing different values could disagree over block validity, making the final rc4 configuration critical before participants attempt to follow the same chain.

The proof-of-work change itself would be permanent. The reduced-data restrictions, including the smaller block cap, are scheduled to expire in 2027.

Sunday’s rehearsal should therefore clarify the activation height, block limit, and other parameters that determine whether participating nodes can remain on one ledger.

A Functional Chain Still Requires an Economy

Even if miners produce blocks under a common ruleset, the harder coordination test begins outside Bitcoin Knots. The proposed fork changes the block header to a 164-byte format using BLAKE2b, while existing Electrum-style clients expect Bitcoin’s 80-byte SHA-256d headers.

That means light wallets, indexers, explorers, and related infrastructure may need changes before they can follow the new ledger. Dashjr said light-client compatibility falls outside Bitcoin Knots’ scope.

The project’s FAQ advises exchanges to pause deposits and withdrawals around the split and announce which chain they will recognize. Lightning channels created before the fork would also exist on the BLAKE2b chain, requiring both peers to use compatible software and agree on the same ledger.

The two networks would inherit the same pre-fork transaction history and coin balances, creating replay risk because a transaction spending pre-fork coins could potentially be valid on both chains.

Bitcoin Knots has proposed a SIGHASH_UNIFIED signing mode that can provide directional replay protection when explicitly selected, but it would not automatically protect every existing wallet or transaction.

The switch to BLAKE2b also addresses only proof of work. It does not replace Bitcoin’s existing addresses, private keys, or transaction signatures, meaning it does not make ownership keys quantum-safe.

The immediate question this weekend is whether Bitcoin Knots can produce and maintain a BLAKE2b chain after BIP-110 failed. The larger test begins if it succeeds: whether miners keep producing blocks and exchanges, wallets, custodians, and users recognize enough economic value in the new ledger to keep it alive.

Source link