The Bitcoin Debate: Ossify or Change

The exploit of Litecoin last week shows why Bitcoin users are wary of adding complexity to a monetary base layer. A day earlier, Bitcoin developer Paul Sztorc announced an eCash fork of Bitcoin in what reflects the counter-argument: that Bitcoin’s resistance to new functionality at the consensus layer carries real risks for its long-term survival and relevance. Together, they sharpen one of Bitcoin’s hardest open questions.

On April 25, 2026 a day after Bitcoin developer Paul Sztorc announced his plans for an August hard fork, Litecoin suffered a setback after an attacker exploited a vulnerability in the protocol’s Mimblewimble Extension Block (MWEB) layer. While the two events are in no way related, their timing has shone light on a debate that has characterised Bitcoin development for over a decade: just how much complexity should a monetary network accept in order to support new functionality and broader use cases — and what are the costs either way?

The MWEB Incident at a Glance

Activated in May 2022, MWEB is an optional feature for Litecoin users, allowing those who want greater privacy to peg LTC into an extension block layer. Yet as the incident revealed, optional use does not necessarily mean optional validation complexity. Once MWEB became part of Litecoin’s consensus rules, it also became something miners and nodes had to validate correctly.

According to Litecoin’s official MWEB postmortem report, developers had already identified the exploit path and patched it privately for miners in late March. In a proof-of-work network, however, upgrades depend on voluntary coordination. Since the fix was handled through miner patching rather than a widely adopted public upgrade, parts of the mining network remained exposed. When the same path was used again in April, upgraded nodes rejected the malformed block while unupgraded miners continued building on the invalid chain, which eventually ran for 13 blocks before upgraded miners coordinated to overtake it. By that time, several third-party swap protocols had processed transactions against it. The episode was resolved fairly quickly, but only after emergency coordination across mining pools and multiple staged releases.

Litecoin is not Bitcoin, and the incident does not map directly onto any specific Bitcoin upgrade proposal. The relevance is broader, highlighting that once new functionality enters consensus, the risk is no longer confined to the users who choose to use it. It adds validation logic, edge cases and operational burdens for the network as a whole. 

The MWEB incident does not show that any Bitcoin proposal would repeat Litecoin’s failure. It shows why consensus-level changes are judged not only by what they enable, but by the assumptions, failure modes and coordination demands they introduce.

A Hard Fork Built Around Drivechains

After years of unsuccessful attempts to get his Drivechain proposals adopted on Bitcoin through community consensus, Paul Sztorc, CEO of LayerTwo Labs, announced on April 24 plans to force the issue through a hard fork called eCash.

Scheduled for block height 964,000 in August 2026, the fork will give every BTC holder eCash at a 1:1 ratio and include tools to help users safely separate the two assets.

The new chain would activate Sztorc’s long-debated Drivechain proposals: BIP300, which introduces a mechanism for creating sidechains and enforcing withdrawals via miner signalling and BIP301, which allows miners to collect sidechain fees without running dedicated sidechain software. Together, they aim to let developers build sidechains with different rules, enabling features such as smart contracts, privacy tools and prediction markets while keeping that additional functionality off Bitcoin’s base layer. Sztorc has framed the activation path as a Core Untouched Soft Fork or CUSF — an activation route outside Bitcoin Core’s normal merge process, but not outside Bitcoin’s broader consensus risks.

Activating BIP300 and BIP301 on Bitcoin itself would require a consensus change. The eCash fork sidesteps that by launching a separate Bitcoin-derived chain with those rules already enabled. Sztorc argues that the benefit is that new features could live on sidechains rather than in ordinary Bitcoin L1 transactions. The base-layer change required to enable that model, however, has consistently failed to gain sufficient support within Bitcoin’s development and user community.

Sztorc has said he will cancel the fork if Bitcoin activates BIP300 and BIP301 before August, making eCash both an alternative implementation path and a way of forcing the Drivechain debate back into public view.

Why Drivechains Divide Bitcoiners

The rationale behind Drivechains is that sidechains linked to Bitcoin’s hash rate could absorb activity and functionality that currently flows to separate altcoins with weaker security models, while giving miners additional fee revenue from sidechain activity. That second point carries increasing weight as Bitcoin’s block subsidy declines and the network’s security budget — the total reward miners earn for securing it — comes to depend more on transaction fees. Drivechain sidechains could, according to this view, provide additional fee demand without requiring changes to Bitcoin’s issuance rules. If a sidechain failed, the damage should theoretically be contained, preventing Bitcoin’s supply from inflating or the corruption of the main chain’s transaction history.

The objection is that this containment comes with new assumptions, particularly around miner authority. Under BIP300, withdrawal approval is enforced by miners over an extended signalling period — a design intended to make theft costly, but one that gives miners a meaningful role in whether sidechain withdrawals are approved. A coalition controlling sufficient hash power could delay or manipulate withdrawals in ways that harm depositors. More broadly, critics such as Peter Todd argue the proposal adds complexity to Bitcoin’s security model, lacks the kind of fraud-proof mechanism they would want for sidechain withdrawals and creates incentive dynamics that are difficult to model under adversarial conditions.

These objections have been raised consistently since BIP300 was first submitted in 2017, and they have not been resolved to the satisfaction of enough Bitcoin stakeholders to move the proposal forward.

Why Bitcoin is Hard to Change

Bitcoin’s upgrade process has no formal governance layer, with changes requiring something approaching consensus across developers, miners, node operators, exchanges, custodians, businesses and users — a standard that has kept the base layer narrow and, proponents argue, trustworthy.

For many institutional holders, that conservatism is not merely a governance quirk but part of Bitcoin’s appeal. The argument for ossification, i.e. the view that Bitcoin’s base layer should become increasingly difficult to change, treats immutability as a feature rather than a constraint. In that sense, predictability and rule stability become central to the investment case.

The 2017 block size wars have become the go-to precedent for what happens when that consensus fractures. Bitcoin Cash forked at block 478,558 with significant miner support and an explicit technical rationale, inheriting Bitcoin’s full transaction history and codebase. What it did not inherit was Bitcoin’s monetary legitimacy — the accumulated social consensus that makes a monetary network function as one. A fork can copy a network’s code and history, but not the trust that users, exchanges and node operators have chosen to place in it.

eCash will face a version of that same challenge.

The Unresolved Trade-Off

Rightly or wrongly, the Litecoin incident gives fresh impetus to the argument for keeping Bitcoin’s base-layer changes rare, narrow and heavily scrutinised.

Sztorc’s eCash proposal does, however, raise a valid point. If many proposals for extending Bitcoin’s functionality struggle to gain support, development does not stop. It simply migrates elsewhere, namely to networks and execution environments that may have thinner security, less mature tooling or more centralised trust assumptions. Whether that outcome is acceptable depends on how one weighs Bitcoin’s monetary properties against the cost of pushing useful functionality outside Bitcoin’s consensus system.

For many institutions with significant exposure to Bitcoin, it’s far from an abstract debate. Their investment case rests substantially on Bitcoin remaining a narrow, predictable base layer with fixed supply and rules that are resistant to change. Sztorc’s hard fork does not threaten that directly, but the debate it has reopened does ask whether those same properties could make it harder to adopt changes some developers believe Bitcoin needs.

Bitcoin’s upgrade debate is therefore not simply about innovation versus conservatism, but about which risk is greater: changing the consensus layer in ways that could compromise Bitcoin’s reliability, or refusing changes that some developers argue may be fundamental to its long-term survival and relevance.

The post The Bitcoin Debate: Ossify or Change appeared first on Bitfinex blog.