Bitcoin has failed to activate every proposed soft fork since Taproot went live in 2021, leading Drivechain creator Paul Sztorc to argue that the network cannot approve any such upgrade for the foreseeable future.
Paul Sztorc, CEO of LayerTwo Labs and creator of the Drivechain proposal, told crypto.news that BIP-110’s failed activation points to a problem extending far beyond one disputed Bitcoin upgrade.
“All soft forks since Taproot have failed to activate, and this was no exception,” Sztorc said.
His assessment followed the collapse of BIP-110, a proposed temporary soft fork that sought to restrict some forms of non-financial data stored in Bitcoin transactions. The proposal drew only 51 supporting blocks during a 2,016-block difficulty period, leaving miner signaling at 2.53%.
BIP-110 enforcing nodes later split from the dominant Bitcoin network at block 961,632 on Aug. 8. The new branch produced only two blocks before stalling, while the main chain continued processing blocks at its usual pace.
BIP-110 failure points to a frozen Bitcoin upgrade process
The BIP-110 result showed how difficult it has become for developers to secure support for changes to Bitcoin’s consensus rules, according to Sztorc.
The proposal’s voluntary activation process required 55% of blocks to signal support. By Aug. 2, the target had become mathematically unreachable because just 28 of the first 1,108 blocks had signaled, according to earlier miner data.
Its enforcing software still entered a mandatory signaling period at block 961,632. Nodes running BIP-110 then rejected blocks that did not signal support, although most miners continued building on the non-enforcing Bitcoin chain.
By Aug. 9, the minority branch remained frozen at block 961,633 as the main chain moved 111 blocks ahead. OCEAN’s BIP-110 endpoint showed about 257 petahashes per second assigned to the branch at the time, while Strategy Executive Chairman Michael Saylor estimated that roughly 99.85% of Bitcoin’s hash power had remained with the dominant chain.
The two-block chain stall became more severe because the branch inherited Bitcoin’s mining difficulty of 127.48 trillion. Without enough computing power, its miners could not quickly produce the remaining blocks required to reach a difficulty adjustment.
BIP-110, formally called the Reduced Data Temporary Softfork, proposed seven consensus restrictions lasting 52,416 blocks, or approximately one year at Bitcoin’s normal block rate. The rules included an 83-byte cap on OP_RETURN outputs, a 256-byte limit on certain data pushes, and restrictions affecting some Taproot functions.
Supporters, including Bitcoin Knots maintainer Luke Dashjr, argued that the restrictions would reduce arbitrary data storage linked to inscriptions and keep Bitcoin focused on monetary transactions. Critics such as Saylor and Blockstream co-founder Adam Back said the proposal could undermine Bitcoin’s neutrality by rejecting transaction structures that the network currently accepts.
Even OP_CAT faces the same Bitcoin consensus barrier
Sztorc said BIP-110 was not an isolated failure, pointing to the lack of activation for other proposed soft forks since Taproot.
Taproot activated at block 709,632 on Nov. 14, 2021, after miners used the Speedy Trial process to signal readiness. The upgrade introduced Schnorr signatures and new Taproot spending rules without forcing non-upgraded nodes onto a separate blockchain.
Since then, proposals seeking to add features or change Bitcoin’s scripting rules have remained under discussion without activation. Sztorc cited OP_CAT as an example, describing it as a small code change that appeared in Bitcoin’s original software and has attracted support from developers.
“Nothing can — not even OP_CAT, which is just 13 lines of code and was in the original software and had lots of support,” he said when asked how BIP 300 could overcome resistance to consensus changes.
“Bitcoin cannot activate any soft forks, for the foreseeable future.”
OP_CAT would let Bitcoin scripts join two data elements. Satoshi Nakamoto disabled the operation in 2010 over security concerns, but a later proposal sought to restore it through a backward-compatible soft fork.
Supporters say the opcode could help developers create covenants, vaults, bridges and other programmable spending conditions. However, the OP_CAT proposal still depends on technical review and sufficient agreement among Bitcoin developers, miners, node operators and users.
Other proposals face the same coordination problem. BIP-360, for example, proposes a new output type designed to support post-quantum signatures through a soft fork. Its authors present the design as a possible path for users to move funds into quantum-resistant addresses, though activation would require the type of network agreement that Sztorc says Bitcoin can no longer achieve.
Drivechains would move experimentation away from Bitcoin’s base layer
Drivechains are designed to let developers test different rules and applications on opt-in sidechains instead of seeking repeated changes to Bitcoin’s base layer.
Under BIP 300, users could move $BTC between Bitcoin and separate sidechains through a two-way peg. Each sidechain could apply its own rules, allowing developers to test privacy systems, smart contracts, faster transactions, or other functions without requiring every Bitcoin user to adopt them.
Sidechains would also maintain separate brands and software, which Sztorc compared with existing systems such as Liquid and Lightning. Users could choose whether to move funds into a particular chain, while Bitcoin’s base rules would remain unchanged after the initial Drivechain upgrade.
Asked whether multiple Drivechains could fragment liquidity and leave users unsure which implementations to trust, Sztorc compared the model with developers launching separate altcoins.
“Each Drivechain will have its own brand, same as Liquid, Lightning, etc.,” he said.
Drivechains would still face the same immediate obstacle identified in Sztorc’s assessment: BIP 300 itself needs a consensus change on Bitcoin. Without activation, developers cannot deploy its proposed withdrawal system as part of the network’s rules.
“It cannot,” Sztorc said when asked how BIP 300 could overcome the resistance that stopped other proposals.
Miner control remains Drivechain’s central security dispute
BIP 300 would assign Bitcoin miners a major role in approving withdrawals from Drivechains, an arrangement that has drawn concerns about theft, censorship and miner collusion.
Under the proposal, withdrawal requests would remain pending while miners vote on them through Bitcoin blocks. A request receiving enough support over the required voting period could release $BTC from the sidechain peg.
Sztorc said the security model depends partly on the economic value that a popular sidechain creates for miners.
“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.”
Users would therefore need to assess the relationship between sidechain fee revenue, miner incentives, and the value of $BTC held within the peg. Critics argue that miners could coordinate to approve an invalid withdrawal, while supporters contend that attacking a profitable sidechain could destroy future fee income and damage confidence in the system.
For U.S. participants, BIP-110 already demonstrated how American mining operations can become involved in Bitcoin governance disputes. Foundry USA Pool asked mining customers to vote on BIP-110 signaling before the mandatory period, while Strategy, a U.S.-listed company and one of the largest corporate Bitcoin holders, publicly opposed the proposal through Saylor.
The failed fork also created a practical risk for holders because BIP-110 did not include automatic replay protection. Bitcoin developer Kevin Loaec warned that a transaction sent on one branch could potentially be copied to the other, putting pre-fork coins at risk if users tried to move or sell assets on the minority chain without first separating them.
BIP-110 supporters also prepared code for a possible proof-of-work change, which would allow the stalled branch to abandon Bitcoin’s existing mining algorithm. The code included a configurable hard-fork time, although developer Chris Guida described it as a contingency and had not set an activation date.
