Bitcoin Knots is preparing a Sunday rehearsal for a BLAKE2b proof-of-work fork after its previous BIP-110 breakaway chain stalled.
On Aug. 29, Bitcoin developer Luke Dashjr told SHA-2 miners to stop mining ahead of an Aug. 30 test. The proposed breakaway network would replace Bitcoin’s SHA-256d proof of work with BLAKE2b.
Dashjr said Bitcoin Knots 29.4.1rc4 would establish the final SHA-2 block before the change. If the rehearsal succeeds, a final 29.4.1 release could preserve the new chain on Sept. 1. Problems would instead 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 aims to avoid relying on existing Bitcoin miners by permanently moving the breakaway network to hardware using BLAKE2b proof of work.
Bitcoin Knots BLAKE2b test faces unresolved questions
As of Aug. 29, the public Bitcoin Knots release page did not show rc4 or a final 29.4.1 build. Several key proof-of-work changes also remained open.
The proposal had not publicly identified a major exchange, wallet, custodian, block explorer or Lightning implementation committed to supporting the new chain.
A successful BLAKE2b block would demonstrate that the fork can operate, but it would not show that enough miners, infrastructure providers and users are ready to keep the network economically viable.
How BLAKE2b is intended to solve the miner problem
The central change is designed to address the weakness that crippled the earlier BIP-110 branch.
Rather than asking the 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 mining 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.
It remains unclear whether enough miners will participate.
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. Estimated testnet4 capacity stood at only 50 to 70 TH/s.
Those figures were based on unfinished code and do not represent final launch parameters. They nevertheless highlight the challenge facing Sunday’s test: compatible mining machines do not guarantee committed hash rate. Public discussions had not disclosed how much capacity operators had pledged to the mainnet fork.
Block production will therefore be an early measure of whether the new design improves on BIP-110 or simply replaces one mining constituency with another.
Bitcoin Knots still needs final consensus rules
Bitcoin Knots must also settle the precise rules that participating nodes will enforce.
The BLAKE2b implementation and a related reduced-data proposal remained open as of Aug. 29. The reviewed public materials had also not fixed the mainnet activation height.
A discrepancy remained 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 limits could disagree about whether a block is valid, making the final rc4 configuration critical before participants attempt to follow the same chain.
The proof-of-work change would be permanent. The reduced-data restrictions, including the smaller block cap, are scheduled to expire in 2027.
Sunday’s rehearsal should clarify the activation height, block limit and other parameters needed for participating nodes to remain on a single ledger.
A functioning chain still needs an economy
Even if miners produce blocks under a common ruleset, the more difficult coordination test will take place 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.
Light wallets, indexers, explorers and other infrastructure may therefore need updates 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.
Both networks would 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. It would not automatically protect every existing wallet or transaction.
The move to BLAKE2b addresses proof of work only. It does not replace Bitcoin’s existing addresses, private keys or transaction signatures, and therefore 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 will begin if it succeeds: whether miners continue producing blocks and whether exchanges, wallets, custodians and users recognize enough economic value in the new ledger to keep it alive.
