Bitcoin’s upgrade process has hit a familiar wall, because even a modest soft fork can grind to a halt when incentives do not line up.
- BIP-110 failed to win enough miner support.
- Paul Sztorc says that shows Bitcoin soft forks are effectively stuck.
- Drivechains are his proposed workaround for experimentation.
- Critics point to replay risk, miner power, and governance tradeoffs.
BIP-110, formally called the Reduced Data Temporary Softfork, was designed to make Bitcoin less useful as a cheap storage layer for arbitrary data. In plain English, it aimed to push back on non-financial clutter while leaving Bitcoin’s money function intact.
According to the proposal, the temporary rules would last 52, 416 blocks, or about one year at Bitcoin’s normal block rate. They included an 83-byte cap on OP_RETURN outputs, a 256-byte limit on certain data pushes, and restrictions touching some Taproot-related functionality.
The numbers tell the story. BIP-110 drew only 51 supporting blocks during a 2, 016-block difficulty period, or 2.53% miner signaling. By Aug. 2, the proposal’s 55% activation target was already mathematically out of reach, with only 28 of the first 1, 108 blocks signaling support.
By Aug. 8, enforcing nodes split from the dominant Bitcoin cannot activate any soft forks for now, Drivechain network at block 961, 632. The minority branch produced only two blocks before stalling, and by Aug. 9 it was still frozen at block 961, 633 while the main chain had moved 111 blocks ahead. OCEAN’s BIP-110 endpoint showed about 257 petahashes per second assigned to the branch, while Michael Saylor said roughly 99.85% of Bitcoin’s hash power stayed with the dominant chain.
For a proposal that needed the network to move as one, that was a rough reality check. Bitcoin does not care how tidy your policy memo looks if miners and nodes are not buying it.
Paul Sztorc, the creator of Drivechain and CEO of LayerTwo Labs, used the failure to argue for something bigger than one abandoned proposal: in his view, Bitcoin’s soft-fork path is jammed.
“All soft forks since Taproot have failed to activate, and this was no exception, ” Sztorc said.
“Bitcoin cannot activate any soft forks, for the foreseeable future.”
That is a strong claim, and it should be treated as his argument, not settled fact. Taproot did activate at block 709, 632 on Nov. 14, 2021, through the Speedy Trial process. So Bitcoin can activate soft forks when coordination is broad enough. The real question is whether that kind of coordination is still realistic for new proposals.
Sztorc’s point is that the bar now looks brutally high. Even changes that are technically small can get buried in politics, distrust, miner incentives, and endless debate over what Bitcoin should or should not become. The network’s conservatism protects it, but it also makes progress painfully slow. No free lunch, no magic chain fairy.
He pointed to OP_CAT as a good example. Sztorc described it as “just 13 lines of code, ” and it is indeed one of Bitcoin’s old scripting opcodes, used to concatenate data elements. Satoshi Nakamoto disabled it in 2010. Some developers want to revive it through a soft fork because it could expand Bitcoin’s scripting abilities. Sztorc’s argument is simple: if even that cannot get through, what can?
There is a real split here in Bitcoin culture. One camp wants the base layer kept minimal, rigid, and boring in the best possible way. Another camp wants room for new tools such as post-quantum signatures, covenants, and more expressive scripting. Both sides say they are defending Bitcoin. They just disagree on what threatens it most: stagnation or feature creep.
BIP-110’s supporters framed the proposal as a defense of Bitcoin’s monetary role. Their view is straightforward: if the chain becomes a junk drawer for arbitrary data, node costs rise, validation gets heavier, and the network gets more expensive to run. In that framing, limits on non-financial data are not censorship. They are maintenance.
Critics see the other side of that coin. Once Bitcoin starts deciding which data is acceptable and which is not, it stops looking like neutral infrastructure and starts looking like governed content policy. That is a dangerous road for a network whose legitimacy rests on rules that are supposed to apply evenly, not selectively.
The broader escape hatch here is Drivechain, the sidechain proposal behind BIP 300. Drivechains are meant to let people experiment on separate chains that are linked to Bitcoin through a two-way peg, so BTC can move between the main chain and the sidechain and back again. The pitch is obvious: let innovation happen without dragging Bitcoin’s base layer into every new fight.
But “off-chain” does not mean “no politics.” BIP 300 still requires a Bitcoin consensus change to activate, and miners play a major role in approving Drivechain withdrawals. So the governance problem does not disappear. It just changes form.
“If the chain is popular, it will be generating fees for miners. If this fee revenue is large, relative to the number of circulating coins on the L2, then it will be secure, ” Sztorc said.
That is the theory: if a sidechain becomes economically important, miners have a strong reason to keep the system honest because they earn from it. It is a clean model on paper. In practice, it still depends on miners behaving rationally, not colluding, not censoring, and not turning a neat experiment into a governance headache with a mining pool logo slapped on it.
There are also technical risks that are not just academic nitpicking. Kevin Loaec warned that BIP-110 lacked automatic replay protection. Replay protection matters when a chain split persists, because without it the same transaction can be valid on multiple branches. That can create accidental double-spends, wallet confusion, and exchange chaos. In other words: a very expensive way to discover your edge cases.
The debate around BIP-110 also drew in familiar Bitcoin heavyweights. Foundry USA Pool asked mining customers to vote on signaling before the mandatory period. Michael Saylor publicly opposed the proposal. Luke Dashjr supported the restrictions. Adam Back criticized the proposal as a potential threat to Bitcoin neutrality.
That mix of support and opposition is exactly what Bitcoin governance looks like in practice: messy, fragmented, and impossible to reduce to a simple yes-or-no vote. Miners matter, developers matter, node operators matter, and big economic actors matter too. Nobody gets a clean veto, which is both the point and the problem.
Key questions and takeaways
-
Did BIP-110 activate?
No. It failed to gain enough support, and the enforcing branch stalled after only two blocks. -
Does this prove Bitcoin can never activate another soft fork?
No. That is Sztorc’s view, but Taproot already showed that Bitcoin can activate soft forks when coordination is strong enough. -
Why did supporters want BIP-110?
They wanted to limit arbitrary data on-chain and keep Bitcoin focused on monetary use, rather than turning it into a general storage layer. -
What is Drivechain trying to solve?
It tries to move experimentation to sidechains so Bitcoin’s base layer does not have to absorb every new feature or policy fight. -
What is the catch with Drivechains?
They still depend on Bitcoin consensus and miner participation, so the trust and governance tradeoffs do not vanish. -
Why does replay protection matter?
Without it, the same transaction can be valid on multiple branches after a split, which can create real user losses and operational mess.
The real lesson is not that Bitcoin is broken. It is that Bitcoin is selective by design. The network does not owe anyone an endless feature roadmap, and that stubbornness is part of why it is trusted.
But conservatism has a cost. If base-layer change becomes nearly impossible, innovation will either move elsewhere or keep slamming into the same wall. That is why proposals like Drivechain keep coming back: they are attempts to work around Bitcoin’s governance bottleneck without turning the base layer into a playground for every half-baked idea with a white paper.
Bitcoin remains money-first, and for plenty of users that is exactly the point. The harder question is how much room, if any, should be left for everything else.
Further reading
A few background pieces and primary references that add more context to the BIP-110 debate.
