What is Bitcoin BIP110?

What is Bitcoin BIP110?

BIP 110 is a Bitcoin Imporvement Proposal (BIP) authored and maintained by Dathon Ohm. The proposal introduces consensus restrictions on certain uses of data within Bitcoin transactions.

The proposal's mandatory-signaling period began on 8 August 2026. At block height 961,632, nodes enforcing BIP 110 rejected a block that did not contain the required signal, while nodes not enforcing the proposal accepted it. The enforcing nodes instead accepted a competing signaling block at the same height. This caused the BIP 110 enforcement branch to split from the Bitcoin BTC mainnet from height 961,632 onward.

The signaling block became the first block of the BIP 110 enforcement branch. Although the branch continued to use SHA-256d proof-of-work and the inherited mining difficulty, it attracted only a small fraction of the network hash power. This resulted in long intervals between blocks and prevented the branch from operating at the normal pace.

Development subsequently moved to a Bitcoin Knots hard fork that replaced SHA-256d with BLAKE2b. The final mainnet parameters set block 961,640 as the first BLAKE2b block, following block 961,639, the final SHA-256d block on the branch.^[12]

Bitcoin BIP110 continues the historical BIP 110 enforcement branch as an independent network using BLAKE2b proof-of-work. The BLAKE2b chain became active on 30 August 2026, and Bitcoin BIP110 first mainnet released on 2 September 2026.^[15]

BIP 110 Proposal

BIP 110 was written by Dathon Ohm and credited Luke Dashjr with the original draft and advice. Its initial draft was recorded on 24 October 2025, it was assigned BIP number 110 on 3 December 2025, and it advanced to Complete status on 25 June 2026.^[1]

The proposal described arbitrary-data storage as a burden on node operators and as competition for block space that could otherwise be used for payments. It proposed seven temporary consensus restrictions intended to remain active for 52,416 blocks, approximately one year, while longer-term approaches were considered.

Proposed consensus rules

If the deployment reached its ACTIVE state, blocks would be checked against seven additional rules:

1. Newly created output scripts longer than 34 bytes would be invalid, except that an output beginning with OP_RETURN could contain up to 83 bytes.
2. Individual OP_PUSHDATA* payloads and script-argument witness items longer than 256 bytes would be invalid, with an exemption for BIP 16 redeem scripts.
3. Spending an undefined witness version or undefined Tapleaf version would be invalid, although creating an output using an undefined witness version would remain valid.
4. Taproot spends containing an annex would be invalid.
5. Taproot control blocks longer than 257 bytes would be invalid.
6. Tapscripts containing an OP_SUCCESS* opcode would be invalid, including when the opcode appeared in an unexecuted branch.
7. Tapscripts executing OP_IF or OP_NOTIF would be invalid regardless of the condition's result.

The proposal distinguished these consensus rules from relay and mining policies, which determine how nodes handle unconfirmed transactions without changing block validity.

UTXO grandfathering

For most input-side checks, an unspent transaction output, or UTXO, created before activation would be exempt. This was intended to preserve the spendability of outputs created under the earlier rules. Outputs created while the deployment was active would remain subject to the new output-size restriction. All BIP 110 restrictions would cease after the temporary deployment expired.^[1]

Signaling and Activation

BIP 110 used a modified form of the BIP 9 version-bits system. Its deployment was named reduced_data and assigned version bit 4. Miners could signal support by setting that bit in the version field of a block.

The 55% threshold was lower than the 95% threshold commonly used by standard BIP 9 deployments. BIP 110 also replaced a time-based failure deadline with a maximum activation height, introduced a period of mandatory signaling, and added an EXPIRED state that would end enforcement after approximately one year.^[1]

Mandatory signaling and activation were separate stages. During the mandatory-signaling window, enforcing nodes required bit 4 in every block. The seven reduced-data rules would take effect only after the deployment entered LOCKED_IN and later reached ACTIVE. The enforcement branch did not reach height 963,648 under the original schedule, so the original deployment never locked in and the seven restrictions never became active on that branch.

Chain Split

Mandatory signaling began on 8 August 2026 at block 961,632. At this block height, AntPool mined a block without version bit 4. Nodes not enforcing BIP 110 accepted the block, while enforcing nodes rejected it because the height was the beginning of the mandatory-signaling window. The enforcing nodes instead accepted a competing bit-4-signaling block mined by Roughnecks through OCEAN DATUM.^[3][4]

Bitcoin BTC mainnet and the BIP 110 enforcement branch share the same history through block 961,631. That block, the last common block, has the hash 00000000000000000000807f9dc917442a67910426d79ebb2f8aa2149327ce8a.^[2]

After block height 961,632, each group of nodes subsequently treated its own block as the valid block, creating two independent branches.

On 9 August 2026, the official BIP record was changed from Complete to Closed. Its changelog described the reason as a chain split followed by stalled mining.^[1]

Branch History

The enforcement branch initially continued to use SHA-256d, the same proof-of-work algorithm as Bitcoin mainnet. It also inherited a mining difficulty of approximately 127.48 trillion, which had been calibrated for the much larger amount of SHA-256d hash power mining Bitcoin. Only a small fraction of that hash power mined the enforcement branch.

Roughnecks mined the first two branch blocks on 8 August. Later blocks appeared intermittently, with gaps lasting from several hours to more than five days. Block 961,638 was observed on 23 August 2026,^[5] and one additional SHA-256d block, 961,639, was subsequently mined. Under the final mainnet parameters, block 961,639 became the last SHA-256d block before the BLAKE2b transition at height 961,640.^[12]

Bitcoin ordinarily adjusts its mining difficulty every 2,016 blocks. The branch's low block-production rate therefore delayed its progress toward the next adjustment. The BLAKE2b hard fork addressed this operational problem by defining a new proof-of-work system and new starting parameters beginning at block 961,640.

BLAKE2b Hard Fork

On 15 August 2026, Luke Dashjr opened Bitcoin Knots pull request #359, titled Hardfork: New BLAKE2b proof-of-work algorithm.^[6] The work introduced a BLAKE2b proof-of-work calculation and a version-2 block-header format intended to continue the BIP 110 enforcement branch after its stalled SHA-256d period.

The hard fork preserves the branch's earlier Bitcoin history, inherited UTXO set, and SHA-256d branch blocks rather than beginning from a new genesis block. Final mainnet parameters set block 961,640 as the first BLAKE2b block and include checkpoints covering the first BIP 110 branch block, the final SHA-256d block, and the first BLAKE2b block.^[12]

Header and mining design

Bitcoin BIP110 uses a 164-byte version-2 block header. The design includes four selectable ASIC profiles, additional nonce space, fields for an opt-in block-withholding defense, future merge-mining support, block height, and a transaction-count commitment.^[6] The release exposes the additional header fields through the getblockheader and getblock RPC methods.^[15]

General support for the BLAKE2b function does not by itself establish miner compatibility. Hardware, firmware, pool software, and the version-2 header and job formats must work together for a miner to produce valid blocks.

Release path to mainnet

Bitcoin Knots published a sequence of signed release candidates while the BLAKE2b implementation moved from testnet4 testing to mainnet activation. RC1 through RC3 used changing testnet4 activation boundaries. RC4 introduced the mainnet activation at height 961,640, RC5 retained the resulting mainnet chain, and the 29.4.1 release preserved those consensus parameters.

RC4 was tagged on 30 August 2026 at 02:09 UTC.^[13] The first BLAKE2b mainnet block, height 961,640, was mined later that morning at 06:14:39 UTC. Its block hash is 0000000000000050c1e5f69672f459293be14f46e5a494e7a8c8541396f18eeb, and the block uses the new 164-byte version-2 header.^[12]

RC5 was tagged on 1 September at 00:56 UTC and retained the chain that began at block 961,640.^[14] Bitcoin Knots then published 29.4.1.knots20260508 release on 2 September at 19:02 UTC. The final release includes the BLAKE2b proof-of-work algorithm, the temporary 800 kWU block-weight limit, the reduced-data flag-day changes, and the unified opt-in signature hash.^[15]

Replay protection

A change in proof of work does not automatically make ordinary transactions valid on only one chain. Bitcoin Knots pull request #357 introduced the optional SIGHASH_UNIFIED signature mode,^[11] and the implementation was included in the 29.4.1 release.^[15] Signatures that opt in use a different signed message and therefore are not valid under software that does not implement that signature mode.

Transactions using ordinary signature modes can remain replayable between compatible histories. Replay protection therefore depends on using the chain-specific signature mode when separating or spending coins across the two histories.

Mainnet status

Bitcoin BIP110 is operational under BLAKE2b proof-of-work. Block 961,639 is the final SHA-256d block on this branch, block 961,640 is the first BLAKE2b block, and Bitcoin Knots 29.4.1.knots20260508 is the signed final release carrying the mainnet consensus changes.^[12][15]

Network Identity

The split at height 961,632 created a block history separate from Bitcoin (BTC) mainnet. Bitcoin BTC continued on the non-signaling SHA-256d chain, while Bitcoin BIP110 continues the BIP 110 enforcement branch.

At block 961,640, Bitcoin BIP110 transitioned from SHA-256d to BLAKE2b proof-of-work and began using the version-2 block-header format. Block 961,639 is the final SHA-256d block on this branch.^[12] From height 961,640 forward, the chain requires compatible BLAKE2b nodes, miners, wallets, explorers, exchanges, and supporting infrastructure.

Despite these technical differences, Bitcoin BIP110 inherits Bitcoin's blockchain history and UTXO set through block 961,631, together with the BIP 110 enforcement-branch blocks that follow. Holders of eligible pre-split Bitcoin UTXOs may therefore control corresponding coins on both histories. Bitcoin BIP110 is a native proof-of-work coin rather than a token issued through a contract.

Bitcoin BIP110's monetary policy preserves Bitcoin's 21 million coin maximum supply. The hard fork changes the chain's proof-of-work system and other consensus behavior rather than creating an additional token supply on top of the inherited ledger.

The first mainnet implementation is Bitcoin Knots 29.4.1.knots20260508, released on 2 September 2026. Its release notes document the BLAKE2b proof-of-work hard fork, the reduced-data flag-day changes, the temporary 800 kWU block-weight limit, the unified opt-in signature hash, and the version-2 block-header RPC fields.^[15]

Bitcoin BIP110 is the exchange listed name, and BIP110 is its exchange listed ticker.

Verified Chronology

The following timeline presents the key dates and block heights in the history of Bitcoin BIP110, from the original BIP 110 proposal through BLAKE2b mainnet activation and the first Bitcoin BIP110 release.

Verified Primary Sources

Dated source material supporting the historical and technical claims documented on this page.