OP_Return Outrage: Bitcoin's Graybeards Unite Against 'Iatrogenic' Protocol Changes

The Bitcoin protocol is having a moment, and that moment is basically a family reunion where nobody can agree on what constitutes a vegetable. Well-meaning uncles are shouting about sound money while Cousin Kevin keeps asking why his node takes 18 hours to sync. It's cozy, really.

Jimmy Song, co-founder of ProductionReady (a non-profit funding open-source Bitcoin software development), is the latest to sound the alarm: Bitcoin needs a "conservative" node client to preserve its monetary properties and keep network decentralization intact. The organization has what they charmingly call a "bias" against significant code changes unless there's "overwhelming" community support—which, in crypto terms, is about as likely as your landlord accepting rent in sats without complaint.

"The general principle is: if you're not sure a change makes the money better, don't make it," Song told Cointelegraph.

The timing is... not coincidental. Nobody writes three-paragraph tweets about block size limits during a bull market. This is very much a bear-market leisure activity, like learning Rust or arguing about transaction ordering at 2 AM.

Bitcoin Core 30 removed the 83-byte OP_Return data limit, bumping it to 100,000 bytes despite significant pushback. The proposal received about 4 times as many downvotes as upvotes on GitHub, which in open-source terms is basically a standing ovation if you squint. The result? Bitcoin Knots nodes surged to over 21.7% of the network (4,746 nodes) by late 2025, up from roughly 1% in 2024. Apparently, when you mess with the data limits, people get... opinionated.

"The more self-sovereign Bitcoin users are, the more decentralized and resilient the network becomes," Song said. "That means keeping the cost of running a node low enough for ordinary people to do it." Nothing says "ordinary people" like compiling software from source on a Tuesday, but sure, we're all HODLing in spirit.

Enter Wang Chun, co-founder of F2Pool, who took to X to explain why he opposes BIP-110 and BIP-54. His argument: don't apply the "package bill" approach (think US Congress stuffing provisions into must-pass bills) to Bitcoin development. He also dismissed the "timewarp" vulnerability as practically unusable since you can't predict which miner produces the next block. Apparently, predicting BTC price movements is fine, but predicting miner behavior? That's where we draw the line.

And then there's Michael Saylor, who called BIP-110 Bitcoin's "biggest self-inflicted risk" and used the word "iatrogenic" (harm caused by medical treatment) in a tweet about bad ideas driving protocol changes. That's not a term you see every day in crypto discourse. Most people use "rugged" or "rekt." Saylor went full medical school dropout with his vocabulary, and honestly? It lands.

BIP-110 proposes allowing miners to vote on which valid block to accept rather than strictly following the longest-chain rule, with a 55% hash power activation threshold (well below the traditional 95% standard). Pro