Why Bitcoin Can't Activate Soft Forks, Drivechain Creator

BIP-110’s collapse and what it means for Bitcoin upgrades

Bitcoin developers and ecosystem observers were reminded in August 2026 that activating soft forks on the network has become extraordinarily difficult. A recent failed attempt to introduce BIP-110 — the Reduced Data Temporary Softfork — highlighted the coordination and consensus problems that now block even modest, backward-compatible changes. Paul Sztorc, creator of the Drivechain idea and CEO of LayerTwo Labs, argues that the pattern of failed activations since Taproot means Bitcoin is effectively unable to approve new soft forks for the foreseeable future.

What happened with BIP-110?

BIP-110 aimed to impose temporary limits on certain forms of non-financial data within Bitcoin transactions. The proposal proposed seven consensus constraints to be enforced for roughly one year (52,416 blocks). Key technical measures included an 83-byte cap on OP_RETURN outputs, a 256-byte limit on some data pushes, and restrictions that would affect some Taproot-related constructs.

Under the proposal’s voluntary activation mechanism, miners would signal support for a soft fork during a 2,016-block difficulty window. BIP-110 recorded only 51 supporting blocks in that window — roughly 2.53% miner support — falling far short of the required threshold. When BIP-110’s enforcing nodes began rejecting non-signaling blocks at block 961,632, the network split briefly: the enforcing branch produced two blocks before stalling, while the dominant Bitcoin chain continued processing blocks uninterrupted.

Why the minority chain stalled

The minority branch inherited Bitcoin’s mining difficulty at the moment of the split — an enormous 127.48 trillion difficulty. With only a tiny fraction of total hash power supporting that branch, miners on the minority chain were unable to create blocks quickly enough, preventing the branch from reaching the next difficulty adjustment. As a result, it froze at block 961,633 and never regained momentum. Public data suggested roughly 99.85% of hash power remained on the main chain, underlining how miners can effectively veto a soft fork by withholding signaling.

Why this isn’t an isolated failure

Sztorc points to a pattern: since Taproot’s activation in November 2021, no subsequent soft fork has successfully activated. Taproot itself used the Speedy Trial miner-signaling mechanism and introduced major changes (Schnorr signatures and Taproot spending rules) without splitting the network. But later proposals — from small opcode restorations to more structural updates — have not reached consensus.

One prominent example is OP_CAT, an opcode originally present in early Bitcoin software and disabled by Satoshi in 2010. Restoring OP_CAT would be a small code change (reportedly a dozen lines), and proponents argue it enables covenants, vaults, bridges and other programmable spending constructs. Nevertheless, even a minimal change like OP_CAT faces the same entrenched political and economic resistance as larger proposals.

Coordination friction across stakeholders

Soft-fork activation requires alignment across multiple constituencies: core developers who write and review code, miners who can signal or withhold support, node operators who ultimately enforce consensus rules, exchanges and custodial services that manage user funds, and end users who must trust the upgrade path. When any of those groups are unconvinced — or perceive potential economic or political costs — the activation process falters.

Drivechains: moving experimentation off Bitcoin’s base layer

Drivechains (BIP-300) are Sztorc’s proposed alternative to repeatedly changing Bitcoin’s core. Instead of forcing the base layer to adopt new features for everybody, Drivechains would enable opt-in sidechains with their own rules and software. Users could transfer BTC to sidechains through two-way pegs; each sidechain could then experiment with features such as smart contracts, advanced privacy, or different fee models.

The Drivechain model is comparable to existing off-chain systems (Lightning) and federated sidechains (Liquid) in that each chain carries its own brand and software. That allows users and developers to choose which chains to trust and interact with, preserving the base layer’s conservative consensus while enabling faster innovation elsewhere.

But BIP-300 still needs a consensus change

Drivechains would require a one-time soft fork to introduce the withdrawal mechanism and the two-way peg framework. That single activation point is precisely where the current impasse bites: if Bitcoin cannot reliably pass soft forks, Drivechains cannot gain the baseline change they need to exist as a network-recognized facility. Sztorc has been frank: absent a successful soft-fork activation, Drivechains cannot be put in place as a Bitcoin consensus feature.

Miner incentives and the security debate around Drivechains

BIP-300 assigns miners a central role in approving withdrawals from sidechains. Withdrawal requests would sit pending while miners vote on them by including signals in new blocks. If miners collectively approve a withdrawal within the voting window, BTC would be released from the sidechain peg back to the main chain.

Critics fear miner collusion could enable theft or censorship: a coordinated miner majority might approve an invalid withdrawal for profit or political ends. Supporters counter that miners have an economic incentive not to sabotage profitable sidechains: doing so would jeopardize future fee revenue and undermine market confidence. The security model thus depends on the relationship between sidechain fee revenue, miner incentives, and the value of BTC locked on the sidechain.

Assessing the economic calculus

For Drivechains to be defensible, popular sidechains must generate meaningful fee income relative to BTC reserves in the two-way peg. If fee streams are large enough, miners would be disincentivized from attacking withdrawals because destroying the sidechain would reduce their future earnings. Users would need to evaluate sidechain economics, trust models, and the practical risks of miner control before committing funds.

Other proposals stuck in consensus limbo

BIP-360 is an example of a proposal designed to add a new output type via soft fork to support post-quantum signatures. The idea is to offer a migration path to quantum-resistant addresses without hard-forking the protocol. Even so, BIP-360 — like OP_CAT and many other ideas discussed in Bitcoin’s technical forums — remains theoretical until a reliable activation path emerges.

The broader result is a chill on protocol-layer innovation. Important upgrades related to privacy, programmability and future-proofing face a high coordination threshold that developers and stakeholders have so far been unable to meet.

Practical risks highlighted by BIP-110’s failure

The BIP-110 episode showed several operational risks for users and businesses. Notably, the proposal did not include automatic replay protection. In a chain split scenario, transactions broadcast on one branch could be valid on the other, exposing pre-fork coins to accidental duplication and loss if users didn’t take steps to separate funds.

Large U.S.-based mining operations also demonstrated how miners can influence governance. Some pools polled customers about signaling, and public positions from major corporate holders influenced the debate — showing that mining and corporate actors can shape whether Bitcoin upgrades get the votes they need.

Developers preparing for contingencies even drafted a possible proof-of-work change to rescue a stalled chain by switching algorithms, but such options are politically fraught and operationally complex. The mere existence of contingency code underscores the high stakes when consensus mechanisms fail.

What this means for Bitcoin’s future

Bitcoin’s conservative upgrade culture has always placed a premium on safety, stability and backwards compatibility. That conservatism has helped secure the network for years, but it also means gaining consensus for change requires an unusually high bar. The repeated failures to pass soft forks suggest this bar may now be impractically high for many kinds of meaningful improvements.

Two practical pathways could help unblock this impasse. First, upgrading coordination and communication across developers, miners, exchanges and custodians might reduce friction and build trust for limited, low-risk upgrades. Second, pursuing more functionality off-chain or on opt-in sidechains — whether Drivechains, Lightning, Liquid, or independent Layer 2s — allows experimentation without risking the base layer’s consensus.

Balancing innovation with network stability

Both approaches have trade-offs. Enhanced coordination risks centralizing influence if a small set of actors drive decisions, while off-chain experimentation shifts trust and security assumptions away from Bitcoin’s pure on-chain model. The community will need to weigh those trade-offs carefully.

Conclusion: a paused upgrade pipeline and the role of Drivechains

BIP-110’s failure is a clear symptom of a larger challenge: Bitcoin’s upgrade pipeline is effectively paused for soft-fork-style changes that require broad agreement. Paul Sztorc’s Drivechain concept offers a way to reconcile the network’s conservative ethos with the need for innovation by moving experimentation to opt-in sidechains. Yet Drivechains themselves cannot be deployed without a consensus change — the same obstacle that blocked BIP-110.

For now, Bitcoin’s roadmap will likely emphasize careful, well-coordinated upgrades and the expansion of opt-in, sidechain and Layer 2 ecosystems. Those parallel tracks — one conservative and on-chain, the other experimental and opt-in — will determine whether Bitcoin can evolve while preserving the decentralization and security that underpin its value.