BIP-110: The Node Operator's Decision Tree for August 2026

Stay on unmodified Bitcoin Core: nothing to do. Run the activation client — a Bitcoin Knots fork — through the mandatory signaling window: your node starts rejecting every block that doesn't signal, and at current support levels that means following a minority chain with a sliver of network hashrate.

That's the entire decision surface BIP-110 creates for a node operator. What follows is the mechanics, the block heights, and the one wallet edge case worth checking before the window opens — not another round of the governance argument you've already seen.

What BIP-110 Does

BIP-110 ("Reduced Data Temporary Softfork," formerly BIP-444, proposed October 2025 by pseudonymous developer Dathon Ohm with Luke Dashjr among the listed authors) tightens seven limits on arbitrary data at once — output size, OP_RETURN, data pushes, control block size (and by extension, deep Tapleaves), and undefined witness versions — and expires automatically 52,416 blocks after activation, roughly a year. Pre-activation UTXOs are permanently exempt. The activation client is a Knots fork; Core hasn't merged it, and nothing suggests it will. That makes this a UASF by construction: enforcement runs from node to miner, not the reverse.

The Seven Constraints

• New outputs: majority limited to 34 bytes.
• OP_RETURN: limited to 83 bytes.
• Data pushes: limited to 256 bytes.
• Control block: limited to 257 bytes.
• Consequence: Tapleaves deeper than 7 levels become unspendable for the deployment's duration.
• OP_SUCCESS and undefined witness versions: unavailable during deployment.
• Pre-activation UTXOs: permanently grandfathered, even if spent after activation.

That last rule is what separates "your funds could be affected" from "this doesn't touch you" — the wallet section below is precise about which.

If You Run Core: Nothing Changes

BIP-110 is a soft fork, not a hard fork — its rules are strictly tighter than Core's, never incompatible with them. A BIP-110-valid block is Core-valid too, so an unmodified node keeps validating and following the chain with the most cumulative work exactly as it does today. No upgrade, no decision required, no exposure either way.

The only visible change, if the fork activates broadly, is what you see in blocks: the data patterns the rule targets stop showing up, because enforcing nodes reject them and miners chasing frictionless propagation stop including them.

If You Run the Activation Client: You're Betting on a Fork

From block height 961,632, an activation-client node rejects any block that doesn't signal bit 4 in the version field — full stop, even if that block is perfectly valid under Core consensus.

Current miner support sits under 3% for the in-progress difficulty period, against a 55% lock-in threshold, and node adoption is stuck in low single digits, almost entirely Knots users. Running this client today means accepting, going in, that your node may end up on a minority chain: low hashrate, thin liquidity, produced by whichever small miners do signal. That's not a call you walk back cleanly once made.

Your Keys: Unaffected, With One Precise Exception

Short version: nothing. Private keys, seed, custody — none of it depends on which client your node runs, or whether BIP-110 ever activates.

The exception requires every one of these at once: a P2TR UTXO, inside a pre-signed transaction, confirmed and spent during the deployment year, using a Tapleaf that violates the new limits (control block size is the likely culprit), with no other valid spending path. Wallets that let you build arbitrary Miniscript — Nunchuk has been cited as an example — can produce trees shaped exactly like that. If you run complex spending setups — inheritance, multisig with alternate branches, nested timelocks — check with your provider whether any path matches this pattern. Not general caution: this is the precise scenario the proposal describes.

The Block Heights That Matter

These numbers move with every block. Check them live at bip110.org/monitor or any block explorer before acting on anything below.

• 961,632 to 963,647 (projected second week of August 2026): mandatory signaling window. Enforcing nodes reject any block that doesn't signal here.
• 963,648, at the latest: lock-in deadline, if the 55% threshold (1,109 of 2,016 blocks) is met.
• 965,664: activation height, projected early September 2026.
• 52,416 blocks post-activation (~1 year): automatic expiration, no action required.

As of late July 2026, network hashrate sits around 870-940 EH/s and under 3% of blocks in the current difficulty period signal — against a 55% lock-in bar. First signal came from Barefoot Mining via Ocean on March 1, 2026; OCEAN has signaled by default for connected miners since July 15.

Three Ways This Resolves

1. Broad activation. Needs a major pool to flip. Foundry, Antpool, ViaBTC, and F2Pool haven't moved as of this writing; Foundry pushed the call to a hashrate-weighted client vote where non-response defaults to "No."
2. Minority activation. Enforcing nodes split off the moment the dominant chain stops signaling during the mandatory window, continuing on a fork with a small fraction of network hashrate and liquidity.
3. Withdrawal or revision. Current rules stand as-is; nothing changes for anyone who didn't opt into the activation client.

None of these is a forecast. They're the only exits the soft fork's own mechanics allow, given the lock-in threshold and signaling window already fixed in code.

What To Actually Do

• Don't move funds preemptively. Running unmodified Core, there's no custody action this soft fork requires of you.
• Avoid accepting low-confirmation payments during the mandatory window and the days right after, until it's clear which chain carries more work.
• Expect some exchanges to pause deposits and withdrawals as a precaution. Standard practice around any soft fork with split risk, not a sign anything broke.
• If you run a node, know which client and why. Running the activation client should be a deliberate call, never a default.

No Forecast, Just the Mechanics

This isn't a price call, and it doesn't take a side on whether arbitrary data belongs on layer 1 or burdens node operators enough to restrict it — that argument is still live among people with more context than fits here, on both sides. What you can verify yourself, without taking our word for it, is the live signaling state and the current block height.

If you're already running your own node, check live sync status and the network metrics behind this kind of tracking in our Network & Mining section.

Last updated: 2026-07-29