Bitcoin Knots to rehearse BLAKE2b fork on Aug. 30

Bitcoin Knots plans a rehearsal on Aug. 30 that will attempt to replace SHA-256d proof-of-work with BLAKE2b on its proposed breakaway chain. The test aims to produce a final SHA-2 block and flip the network to BLAKE2b; developers have said a successful rehearsal could lead to a full release on Sept. 1.

Developer Luke Dashjr instructed SHA-2 miners to stop mining ahead of the Aug. 30 test and designated Bitcoin Knots 29.4.1rc4 as the candidate to mark the final SHA-2 block before the switch. If problems emerge during the rehearsal, the project plans another release candidate and a reset to the last SHA-2 block.

The attempt follows a BIP-110 split three weeks earlier that produced only two blocks before stalling. The new proposal rejects SHA-256d blocks after activation and requires BLAKE2b-compatible hardware. Supporters cite machines originally built for Sia mining, including Bitmain’s Antminer A3 and Goldshell SC5, as likely compatible devices. Testnet4 mining instructions and a compatible DATUM Gateway fork have been published for operators.

An open-code review estimated an early proposed difficulty would need roughly 870 terahashes per second to maintain 10-minute blocks, while measured testnet4 capacity was about 50 to 70 TH/s. Those figures come from unfinished code and are not final launch parameters. Public discussion has not disclosed pledged mainnet hashing capacity.

Several consensus rules and software changes remained unresolved as of Aug. 29. The BLAKE2b implementation and a related reduced-data proposal were under review, and the mainnet activation height had not been fixed. A temporary block-weight limit differs between documents: a proposal FAQ and pull request list 700,000 weight units, while a pinned source commit sets 800,000. Nodes enforcing different limits could disagree on block validity.

The fork changes the block header format to 164 bytes from Bitcoin’s 80-byte header. Existing light clients and Electrum-style wallets expect 80-byte headers and would not follow the new ledger without updates. Dashjr wrote that light-client compatibility is outside the scope of Bitcoin Knots.

Exchanges have been advised to pause deposits and withdrawals around the split and to announce which ledger they will recognize. Lightning channels opened before the fork would continue to exist on the BLAKE2b chain but require both peers to run compatible software and to agree on which chain to follow.

The proposed chain would inherit pre-fork transaction history and coin balances, creating replay risk for transactions valid on both ledgers. Bitcoin Knots has proposed a SIGHASH_UNIFIED signing mode to allow directional replay protection when explicitly used, but it would not automatically protect all existing wallets or transactions. The BLAKE2b switch affects only proof-of-work and does not change addresses, private keys, or transaction signatures.

Sunday’s rehearsal will attempt to produce and maintain a BLAKE2b chain under a common ruleset. If the rehearsal succeeds and unresolved issues are addressed, developers have indicated a final 29.4.1 release could preserve the new chain on Sept. 1.