Bitcoin Knots is trying to fork Bitcoin again after its last chain died in two blocks

Bitcoin Knots is preparing a Sunday rehearsal for a BLAKE2b fork after its previous breakaway BIP-110 chain stalled.

On Aug. 29, Bitcoin developer Luke Dashjr told SHA-2 miners to stop mining ahead of an Aug. 30 test that would replace Bitcoin’s SHA-256d proof of work with BLAKE2b on the proposed breakaway network.

Dashjr said Bitcoin Knots 29.4.1rc4 would establish the final SHA-2 block before the switch. If the rehearsal succeeds, a final 29.4.1 release could preserve the new chain on Sept. 1. However, 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 stalled after producing only two blocks. The new proposal seeks to avoid another dependence on existing Bitcoin miners by permanently moving the breakaway network to hardware using BLAKE2b proof of work.

But the weekend test begins with several questions still unresolved. As of Aug. 29, the public Bitcoin Knots release page did not show rc4 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, custodian, explorer, or Lightning implementation committed to supporting the new chain.

A successful BLAKE2b block would therefore show that the fork can run. However, it would not establish that enough miners, infrastructure providers, and users are prepared to keep it economically viable.

BLAKE2b tries to solve the miner problem

The central change addresses the weakness that crippled the earlier BIP-110 branch.

Instead of asking SHA-256d miners securing Bitcoin to continue producing blocks for a minority fork, the new chain would reject SHA-256d blocks after activation and rely on BLAKE2b hardware.

Backers say machines originally built to mine Sia, 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 unclear.

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. But they expose the problem 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.

The fork still needs final consensus rules

Bitcoin Knots also has to settle exactly which rules participating nodes will enforce.

The BLAKE2b implementation and a related reduced-data proposal were still open as of Aug. 29, while the reviewed public materials had not yet fixed the mainnet activation height.

There was also a discrepancy 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 whether a block is valid, 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 working chain still needs 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 tells 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 also inherit the same pre-fork transaction history and coin balances.

That creates 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.