Bitcoin Knots is rehearsing a second breakaway chain, three weeks after its first attempt, BIP-110, stalled having produced only two blocks. The new version drops Bitcoin's SHA-256d proof-of-work for BLAKE2b to stop relying on existing Bitcoin miners, but no major exchange, wallet, or Lightning implementation has yet committed to supporting it.
Developer Luke Dashjr told SHA-2 miners to stop mining ahead of an Aug. 30 test that would swap Bitcoin's SHA-256d hashing for BLAKE2b on the proposed breakaway network. Dashjr said Bitcoin Knots 29.4.1rc4 would mark the final SHA-2 block before the switch, and a successful rehearsal could preserve the new chain in a 29.4.1 release on Sept. 1. However, any problems would trigger another release candidate and reset the chain to the last SHA-2 block.
BLAKE2b tries to escape the miner dependence that killed BIP-110
The switch targets the weakness that ended the earlier attempt: rather than asking SHA-256d miners securing Bitcoin to keep producing blocks for a minority fork, the new chain would reject SHA-256d blocks after activation and rely on BLAKE2b hardware instead. Backers say machines built for Sia mining, including Bitmain's Antminer A3 and Goldshell SC5 models, can support the new proof-of-work system, and testnet mining instructions have already been published.
Whether enough miners will actually show up is unclear. A reviewer of the open implementation calculated that one proposed initial difficulty setting would need roughly 870 terahashes per second to hold 10-minute blocks, while measured testnet capacity was estimated at only 50 to 70 TH/s. Those figures come from unfinished code and are not final launch parameters, but they underline that compatible mining machines existing doesn't guarantee committed hash rate.
Consensus rules are still unsettled going into the test
Bitcoin Knots also has to fix exactly which rules participating nodes will enforce. As of Aug. 29, the mainnet activation height had not been set, and there was 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, so the rehearsal needs to clarify the activation height and block limit before participants can follow the same chain. The proof-of-work change itself would be permanent, though the reduced-data restrictions are scheduled to expire in 2027.
Wallets and exchanges face their own compatibility test
Even if miners produce blocks under one ruleset, the harder coordination happens outside Bitcoin Knots. The fork changes the block header to a 164-byte BLAKE2b format, while existing Electrum-style wallets expect Bitcoin's 80-byte SHA-256d headers, meaning light wallets, indexers, and explorers 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, and Lightning channels opened before the fork would need both peers running compatible software.
The two networks would also inherit the same pre-fork transaction history and coin balances, which creates replay risk since a transaction spending pre-fork coins could 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.
Source: CryptoSlate
Trading involves risk.
Risk Disclaimer
