Bitcoin BIP110 Nodes Guide

Overview

This guide provides practical information for operating a Bitcoin BIP110 full node following the network's transition from SHA256d to BLAKE2b proof of work. The BLAKE2b chain began at block 961,640, after block 961,639, the final SHA256d block on this branch.

Running Bitcoin BIP110 requires a Bitcoin Knots version that includes the BLAKE2b consensus changes. Bitcoin Core and older Bitcoin Knots releases continue to require SHA256d and therefore follow a different blockchain after the split.

The source material distinguishes two consensus events. BIP 110 enforcement began at block 961,632. The later BLAKE2b hardfork began at block 961,640, after block 961,639, the last SHA256d block on this branch. The temporary reduced-data rules were moved to the BLAKE2b activation height rather than beginning on 8 August.

Node situation	What to do
Already running the BLAKE2b-capable Knots build	Continue using the existing Bitcoin data directory. A blockchain re-download is normally not required.
Switching from Core or older Knots	Install the BLAKE2b-capable Knots build. It will usually walk back post-fork SHA256d blocks and then download the BLAKE2b chain.
Pruned node missing required old blocks	A complete chain download may be required if the blocks needed for the automatic walk-back are no longer available locally.
Database contains an invalid BLAKE2b block	Use `-reindex` to rebuild the block database from locally stored block files.

Chapter 1

Node Software

Which software should I use for Bitcoin BIP110?

The current and only implementation of Bitcoin BIP110 is Bitcoin Knots containing the BLAKE2b proof-of-work hard fork and associated consensus updates.

The current Bitcoin Knots build is here.
The source code is in the Bitcoin Knots Github repository.
Report bugs through the Bitcoin Knots issue tracker.
Stay up to date by subscribing Bitcoin Knots mailing list.

Which operating systems are supported?

The following operating systems are supported:

Linux
macOS 13 and later
Windows 10 and later

Running the software on unsupported operating systems is not recommended.

How do I upgrade the software?

Shut down the node before replacing or upgrading the software.

Windows: run the new installer after the old node has fully shut down.
macOS: replace the existing /Applications/Bitcoin-Qt application.
Linux: replace the bitcoind and/or bitcoin-qt binaries.

Direct upgrades from very old Bitcoin Core or Bitcoin Knots versions are possible. The data-directory migration may take additional time. Older Bitcoin Knots wallets are supported.

Chapter 2

Existing Bitcoin BIP110 Nodes

I already upgraded before the BLAKE2b fork. What do I need to do?

If your node is already running the BLAKE2b-capable Bitcoin Knots software, you can continue using your existing data directory normally.

A blockchain re-download is not required simply because of the hardfork and you do not need to move funds as part of the upgrade.

Important: Keep the existing data directory when upgrading. Deleting it unnecessarily can turn a simple software upgrade into a complete blockchain re-download.

Does the BLAKE2b hardfork require a new data directory?

No. The operators who already upgraded can continue using their existing data directory.

The software continues from the existing blockchain data and follows the BLAKE2b branch under the new consensus rules.

Chapter 3

Switching from Core or Older Knots

What happens if my node followed the SHA256d chain after the split?

Bitcoin Core and older Bitcoin Knots releases may have continued following the SHA256d blockchain after the Bitcoin BIP110 branch moved to BLAKE2b.

When a BLAKE2b-capable Knots node starts using an existing data directory, it will typically recognize that the local chain contains SHA256d-mined blocks beyond the BLAKE2b fork point. It will roll back the local chain state to that fork point, discard the incompatible continuation, and then download and validate the BLAKE2b chain from there.

The automatic walk-back applies to SHA256d blocks at or after the fork. This allows many operators to migrate without deleting the entire blockchain and starting again.

Do I need to delete my blockchain first?

Typically no. BLAKE2b-capable releases performs the required walk-back automatically when the local node has followed post-fork SHA256d blocks.

The exception are if the local data needed for recovery is unavailable or the database cannot be repaired through the normal migration process. For these cases, a full re-download is required.

Important: Bitcoin Core and older Bitcoin Knots releases do not become Bitcoin BIP110 nodes simply by connecting to Bitcoin BIP110 peers. They require software that implements the BLAKE2b consensus change.

Chapter 4

Pruned Nodes and Reindexing

What if my node is pruned?

A pruned node deletes older block files to reduce disk usage. This can affect migration if the node followed the SHA256d chain after the split and later needs those blocks that have already been deleted.

If the blocks required for the walk-back have been deleted then the node may need to rebuild and download the blockchain again. The current release will prompt the user if a resync is required.

When should I use `-reindex`?

The automatic post-fork walk-back is specifically for SHA256d blocks at or after the fork. Run -reindex if a BLAKE2b block itself caused an invalid local block-index state because it violated the applicable data or sizing rules.

Reindexing rebuilds the block database from the block files available locally. This is different from redownloading the entire blockchain again.

Situation	Expected recovery path
Post-fork SHA256d blocks are present locally	Normal startup should walk back those blocks and continue on BLAKE2b.
A BLAKE2b block caused an invalid block-index state	Start the node with `-reindex`.
Pruning removed blocks required for recovery	Rebuild and download the blockchain again.
Late upgrade followed invalid blocks and cannot recover locally	Rebuild and download the blockchain again.

Chapter 5

What Nodes Enforce

The BLAKE2b-capable Bitcoin Knots release is a incompatible to the Bitcoin BTC. It is only compatible with the new Bitcoin BIP110 branch using BLAKE2b proof-of-work

BLAKE2b proof-of-work

Bitcoin BIP110 changed the Bitcoin BTC proof-of-work consensus from SHA256d to BLAKE2b beginning at block 961,640. Software that require SHA256d cannot validate new Bitcoin BIP110 blocks as part of this chain.

Reduced-data rules

The BIP 110 reduced-data restrictions began at block 961,640 and continue to be enforced. In addition to these restrictions, there is an additional block limit of 800,000 weight units, approximately 300 kB serialized.

Coins created before the fork remain spendable under the earlier script rules.

Peer discovery and networking

Bitcoin BIP110 also includes peer-to-peer networking changes that request peers advertise NODE_BLAKE2B. This helps compatible nodes identify peers participating in the Bitcoin BIP110 network.

In addition to preferring NODE_BLAKE2B peers, Bitcoin BIP110 includes a testnet4 DNS seed and changes DNS-seed behavior so startup peer discovery is based on the number of NODE_BLAKE2B peers available.

Replay protection for cross-chain spending

Bitcoin BIP110 includes the opt-in SIGHASH_UNIFIED signature format for transactions that could also be valid on Bitcoin BTC. Without replay protection, a transaction spending pre-fork coins on Bitcoin BIP110 could potentially be copied and broadcast on Bitcoin BTC as well.

To separate your coins safely, first send them to yourself using SIGHASH_UNIFIED and wait for the transaction to confirm. This creates a BIP110-specific spend that cannot be replayed on Bitcoin BTC.

Version 2 block headers and RPC output

The Bitcoin BIP110 also introduces a new 164-byte version 2 block header designed around the new mining system. In addition to the traditional Bitcoin header fields, it adds expanded nonce space, miner-side time rolling, a transaction-count commitment, optional block-withholding protection, multiple ASIC input profiles, and a hook for future merge mining.

The getblockheader and getblock RPCs expose these fields through header_version, nonce2, nonce3, extranonce, time_offset, header_flags, xor_key, xor_key_mask_clear_bits, and mm_rhs.

The new txcount field reports the transaction count committed by a version 2 header when available. The older nTx field remains for compatibility but is deprecated.

Additional validation and protocol changes

The Bitcoin BIP110 includes several protocol-hardening changes. It addresses validation-cost attacks involving deliberately expensive blocks (CVE-2013-2292), a transaction-signing weakness that can result in unexpectedly large fees (CVE-2020-14199), and the Merkle-tree ambiguity behind CVE-2017-12842. The new version 2 header addresses the latter by committing the block's transaction count directly into the header.

The redesigned header also introduces an opt-in defense against worker block-withholding attacks, expands the mining search space to reduce work for ASIC controllers, and adds a hook for future merge-mined sidechains. Its layout also reserves a path toward extending Bitcoin's 32-bit block timestamp to 40 bits, although activating 40-bit timestamps would require a future hardfork.

The Bitcoin BIP110 also changes how the network activates and validates its consensus rules. The temporary reduced-data rules activate automatically at flag day, so the first Blake2b blocks will satisfy those restrictions without a separate miner-signaling process.

Bitcoin BIP110 updates the built-in mainnet and testnet4 parameters and checkpoints to describe the new chain and its activation points. It also adds an internal block-index consistency check after InvalidateBlock changes chain state, helping detect problems while a node rolls back or reorganizes its local chain.

Because the reduced-data rules are built directly into Bitcoin BIP110's scheduled consensus transition, the earlier consensusrules=rdts user-consent mechanism is removed.

Transaction policy

Bitcoin BIP110 also enables the rejecttokens spam filter by default and extends that filter to identify counter-party transactions.

Chapter 6

Verification and Troubleshooting

How do I know that my node is on Bitcoin BIP110?

First, verify that you are running a Bitcoin Knots build that explicitly includes the BLAKE2b hardfork changes. Bitcoin Core and older Bitcoin Knots versions will remain on SHA256d and therefore cannot serve as Bitcoin BIP110 nodes.

Next, verify that your node has synchronized beyond block 961,640 on the chain and compare the chain tip against an independent Bitcoin BIP110 network explorer .

For protocol-level inspection, Bitcoin BIP110 exposes the new version 2 header fields through the getblockheader and getblock RPCs.

My node appears stuck on the SHA256d branch. What should I check?

Confirm that the installed Bitcoin Knots build includes the BLAKE2b hardfork.
Allow the software to complete its automatic walk-back of post-fork SHA256d blocks.
If the node is pruned, determine whether the blocks required for recovery are still available locally.
If the local state contains an invalid BLAKE2b block-index condition described by the release, use -reindex.
If local data is insufficient for recovery, rebuild the node and download the blockchain again.

Which RPC checks can confirm BLAKE2b activation?

Check getblockchaininfo and getdeploymentinfo. For a synchronized Bitcoin BIP110 mainnet node, blake2b.height should be 961640 with blake2b.active set to true, and the reduced_data deployment should report the same activation height and the active state.

Known release issues

A virtual-size reporting discrepancy remains in some GUI and RPC views. The transaction-details dialog and several vsize fields may omit penalties from unusually high signature-operation counts or datacarrier usage, causing the displayed virtual size to appear smaller than the effective size used by mempool and mining policy.

Do I need to move my Bitcoin BIP110 before changing node software?

No. Moving coins is not required for the node migration and coins created before the fork continue to be spendable.

Sources

Technical Changes

Knots #357 - Unified opt-in sighash for all transaction types.
Knots #358 - Activate reduced-data rules at the proof-of-work hardfork flag day.
Knots #359 - New BLAKE2b proof-of-work algorithm.
Knots #360 - Check the block index after InvalidateBlock repairs it.
Knots #385 - BLAKE2b mainnet and testnet4 parameters and fork checkpoints.
Knots #368 - Prefer NODE_BLAKE2B peers.
Knots #375 - Add the Léo Haf testnet4 seed.
Knots #386 - Find and prefer NODE_BLAKE2B peers during startup.
Knots #349 - Reject Counterparty messages under -rejecttokens.
Knots #354 - Enable rejecttokens by default.
Knots #377 - GUI build fix for MempoolStats::drawChart.
Knots #363 - Expose version 2 block-header fields through RPC JSON.
Knots #362 - Remove the reduced-data consent requirement.

Running a Bitcoin BIP110 Node