This hardfork is not BIP-110. BIP-110, in alignment with the vast majority of node policy, was a softfork, later rejected, that would have rejected use of the network for arbitrary data storage. This hardfork was a denial of abuse of the Bitcoin network, and changed proof of work from SHA256d to BLAKE2b, a different algorithm, so today's SHA256d miners cannot produce valid blocks here. The first BLAKE2b block is 961640 (30 August 2026).
Limits on arbitrary data storage began at height 961640 as a flag day, together with BLAKE2b, not on August 8 and not as a leftover versionbits vote. They apply to v2-header blocks until the previous block's median time past reaches 1 September 2027, 00:00 UTC. During that window, blocks are also limited to 800,000 weight units, about 300 kB serialized. Inputs that spend coins created before the fork are exempt from the new script and data rules.
Each BLAKE2b block uses a 164-byte header v2, not the classic 80-byte SHA256d header. Light-client protocols that hash an 80-byte header with SHA256d will not validate this chain until they learn the new format and BLAKE2b.
Integration checklist
- Use a BLAKE2b node, not Bitcoin Core or a pre-hardfork Bitcoin Knots release, if you intend to follow this chain. Source: bitcoinknots/bitcoin.
- If a node followed post-fork SHA256d blocks, this release usually walks back to the fork and downloads the BLAKE2b chain. That pass uses headers only. A BLAKE2b-era block that breaks the weight cap, output sizes, or script rules still needs
-reindex. A pruned node that has already deleted the walk-back blocks must resync. - After the previous block's median time past reaches 1 September 2027, 00:00 UTC, the data limits and the weight cap are removed unless node operators later choose to continue them. BLAKE2b proof of work is not temporary.
getdeploymentinforeportsreduced_dataas a flag-day deployment.getblocktemplateadvertises BLAKE2b as!blake2binrules, and listsreduced_datathere only while the window is open. There is no miner signaling bit.getdeploymentinfoalso reportslong_coinbase_maturityas a flag-day deployment (height / enforce 973440, height_end 979919, maturity 6480). While the tip is in that window it is active. Coinbases created at height 973440 or later need 6480 confirmations before they can be spent in a block; coinbases from before 973440 stay on the old 100-block rule for block consensus. On Knots 29.4.2 the wallet and this node's mempool apply 6480 to every coinbase. Ordinary (non-coinbase) bitcoin is unchanged. See the solo mining guide.- SHA256d difficulty and BLAKE2b difficulty are different units. Knots 29.4.2 removes
getdifficultyand the SHA256d-styledifficultyfield where it no longer applies, and addsdifficulty_blake2bfor BLAKE2b blocks (including ingetblockchaininfo). - Wallets should implement the opt-in
SIGHASH_UNIFIEDsighash from Knots PR 357: one BIP341-shaped message, bit0x20, taggedUnifiedSighash. That removes CVE-2013-2292 and CVE-2020-14199 for inputs that opt in. Replay protection is a consequence of the distinct message, one-way, and only for signatures that set the bit. Ordinary signatures stay valid and still replay. If a holder intends to sell, gift, or spend the fake “bitcoins” on the SHA256d altcoin launched by former miners, the intended action is a send-to-self on this chain with that format, then wait for the payment to confirm, before spending the same coins on the other chain. See doc/unified-sighash.md.
Miners constructing their own templates should use the DATUM Gateway with Knots. See miners and DATUM.
The proof-of-work change is specified in Knots PR 359. The reduced-data flag day and MTP expiry ride that block height in PR 358. Long coinbase maturity is PR 419. The opt-in unified signature hash is PR 357.
Read the release notes, node operator guide, and FAQ.