From BIP 110 to an independent BLAKE2b chain

The original BIP 110 proposal

Purpose and motivation

BIP 110, officially titled Reduced Data Temporary Softfork, proposed temporary additional consensus restrictions on several transaction data fields. Its stated objective was to reduce the cost imposed on node operators by arbitrary-data storage, preserve block space for monetary use, and signal that general-purpose data storage was outside the author's intended scope for Bitcoin. The proposal described a one-year intervention while longer-term alternatives could be developed.

The seven proposed consensus restrictions

While the deployment was ACTIVE, blocks would have been checked against these rules:

1. A newly created output scriptPubKey longer than 34 bytes would be invalid. An output beginning with OP_RETURN could be up to 83 bytes.
2. OP_PUSHDATA* payloads and script-argument witness items longer than 256 bytes would be invalid. The redeemScript push in a BIP 16 scriptSig was exempt.
3. Spending an undefined witness version or undefined Tapleaf version would be invalid. Creating an output using an undefined witness version would remain valid.
4. A Taproot spend containing an annex would be invalid.
5. A Taproot control block longer than 257 bytes would be invalid.
6. A Tapscript containing an OP_SUCCESS* opcode anywhere, including an unexecuted branch, would be invalid.
7. A Tapscript that executed OP_IF or OP_NOTIF would be invalid regardless of the condition's result.

These were proposed consensus restrictions, separate from relay and mining policy defaults.

UTXO grandfathering

For input-side script and witness checks, an input spending a UTXO created before the RDTS activation height would be exempt. The design allowed pre-activation outputs to remain spendable under the rules that existed when they were created. New outputs created while RDTS was active would still be subject to the output-size rule. Once the temporary deployment expired, UTXOs of every height would again be unrestricted by RDTS.

Modified versionbits deployment

The BIP used a modified BIP 9 state machine with deployment name reduced_dataand version bit 4.

The lower threshold, height-based activation deadline, mandatory-signaling interval, and temporary EXPIRED state deviated from standard BIP 9. A successful mandatory window would place the deployment in LOCKED_IN at height 963,648 and ACTIVE one 2,016-block period later at height 965,664. If activated there, the rules would apply through height 1,018,079 and expire at 1,018,080.

The enforcement-chain split

The common parent and first divergent blocks

Both histories contain block 961,631, the last shared block. Its hash is 00000000000000000000807f9dc917442a67910426d79ebb2f8aa2149327ce8a.

At height 961,632, AntPool mined a block without version bit 4. Nodes following ordinary Bitcoin rules accepted it. BIP 110 enforcing nodes rejected it because this was the first block of the mandatory-signaling window. Those nodes accepted a competing bit-4-signaling block mined by Roughnecks through OCEAN DATUM.

The blocks have the same parent and different transaction sets. From height 961,632, the two groups of nodes follow different block histories.

Early SHA-256d mining history

The enforcement branch initially remained on SHA-256d at Bitcoin's inherited difficulty. Roughnecks mined blocks 961,632 and 961,633 on 8 August 2026. Later blocks appeared intermittently. The observed tip on 24 August 2026 was height 961,638, hash 000000000000000000002e54f5ee1567dca91a3e169d983e30786956a617ca5f.

The dated record shows very slow and intermittently stalled production. Any current status should time-stamp its observed tip.

Mandatory signaling was separate from RDTS activation

Mandatory signaling determined which blocks enforcing nodes accepted during the final pre-lock-in period. The seven reduced-data restrictions would become consensus rules only after LOCKED_IN, at the later ACTIVE boundary. The branch never reached height 963,648, so the original deployment never locked in and its seven RDTS restrictions never became active there.

Bitcoin BIP110 and BLAKE2b

Continuation as an independent chain

After the SHA-256d branch separated and advanced too slowly for normal operation, development shifted toward continuing it through an explicit proof-of-work hard fork. On 15 August 2026, Luke Dashjr opened Bitcoin Knots pull request #359, titled Hardfork: New BLAKE2b proof-of-work algorithm. The proposed client accepts SHA-256d blocks before a configured activation height and requires BLAKE2b header-v2 blocks at and after that height.

The intended lineage preserves the enforcement branch's Bitcoin history, UTXO set, and SHA-256d branch blocks before activation. It does not begin from a new genesis. The exact mainnet anchor, parent block, and activation height remain pending until fixed in signed mainnet source.

Why the SHA-256d branch was constrained

The split occurred at a Bitcoin difficulty-adjustment boundary. The branch inherited difficulty of approximately 127.48 trillion, calibrated for the dominant Bitcoin network's hash rate. A small fraction of that rate mined the enforcement branch. Bitcoin's ordinary adjustment occurs every 2,016 blocks, so low hash rate also delayed its ability to reach the next adjustment. The multi-day block gaps followed.

A proof-of-work change creates a boundary for a BLAKE2b-specific target adjustment and a different installed base of mining hardware. It also prevents SHA-256d Bitcoin ASICs from mining post-activation blocks under the new rules.

Why BLAKE2b was selected

Pull request #359 targets compatibility with proof-of-work hardware from several vendors. Its 164-byte header-v2 design includes four selectable ASIC profiles, more nonce space, an opt-in block-withholding defense, future merge-mining fields, block height, and transaction-count commitments. The practical target is Sia-style BLAKE2b hardware.

Compatibility must be demonstrated for each miner and firmware combination. A chip that computes BLAKE2b does not establish compatibility with the header serialization and Stratum job format.

Testnet implementation and activation

The testnet4 guide records validation across height 149,537 and warns that the release candidate is unmerged, source-only, and subject to change. RC2 couples the BLAKE2b transition, RDTS activation, and unified signature-hash activation at one testnet height. This does not establish final mainnet composition.

Reference client and mining stack

As of 24 August 2026, pull request #359 remained open and described itself as an unfinished draft. It implements header-v2, a height-based proof-of-work transition, first-block target adjustment, ASIC profiles, validation tests, and mining interfaces. No signed stable mainnet release had been published.

The ordinary DATUM Gateway does not support this BLAKE2b work. The test setup uses a BLAKE2b-capable DATUM Gateway fork that requests templates with the blake2brule, constructs header-v2 Stratum jobs, and selects the algorithm and ASIC profile. The Antminer A3 is explicitly named. Other BLAKE2b-Sia miners require end-to-end testing. SHA-256d ASICs cannot be converted into BLAKE2b miners through firmware alone.

Mainnet activation status

No BLAKE2b mainnet activation height was present in the development branch or RC2 mainnet parameters on 24 August 2026. The default mainnet Blake2bHeightremained unscheduled. Rumored dates or heights are not activation parameters.

A stable record should include a signed tag, commit, activation height and parent hash, BLAKE2b target shift, RDTS rule, coinbase commitment, replay rule, test vectors, and binary signatures. The network becomes operational under BLAKE2b after a valid activation block is mined and independently observed.

Replay-protection design

Proof-of-work separation does not make transactions chain-specific. Bitcoin Knots pull request #357 proposes SIGHASH_UNIFIED = 0x20, which changes the signed message when a signer opts in. A protected signature under that algorithm fails verification on a chain that does not implement it.

The design is opt-in and one-directional. Transactions signed withoutSIGHASH_UNIFIED remain potentially replayable between compatible histories. Protection attaches to each signature rather than a particular UTXO age. The testnet release candidates contain the implementation, but no active mainnet rule had been published.

An independent network and native coin

The split at height 961,632 created an independent block history. A mainnet BLAKE2b activation would add another explicit consensus boundary through a new proof-of-work algorithm and header format. Bitcoin BIP110 would operate with its own nodes, miners, wallets, infrastructure, and inherited pre-split UTXOs. It is a native coin, not a token, and has no contract address.

Bitcoin BIP110 and BIP110 are project-facing name and ticker declarations. Names and tickers are not consensus fields, and exchanges or data services may assign different identifiers.