The OP_RETURN change in Core v30 is just a relay policy default adjustment - from ~80 bytes to 100,000 bytes (effectively uncapped since tx size limits hit first anyway). It changes nothing about consensus rules. Nodes can still set -datacarriersize to whatever they want (including back to 83 bytes) in their own config. Miners and pools were already free to include whatever valid txs they wanted, and data could already be embedded via other methods (multi-output nulldata workarounds, Taproot scripts, etc.). The old 80-byte limit was never a hard consensus barrier; it was always just a relay convention that got bypassed when incentives were high enough. v30 simply stops pretending a tiny policy knob stops determined users. It's harm reduction and honesty about reality, not some radical protocol shift. BIP-110, on the other hand, is the actual controversial escalation here. It tries to impose a new consensus-level hard cap on arbitrary data outputs (back to 256 bytes or similar strict limits) via a soft fork. That would change what has been valid under Bitcoin's rules for years, forcing a network-wide upgrade debate, potential chain split risks if activation thresholds aren't met cleanly, and overriding node/miner sovereignty on what they consider valid blocks/transactions. Policy defaults are opt-in/opt-out per node. Consensus changes are not. One is a configurable relay choice, the other is attempting to rewrite the monetary policy envelope through code that many see as overreach. If you're worried about 'centralization' or 'intentional protocol shifts,' look at the side pushing a user-activated soft fork to enforce their view of 'proper' Bitcoin use on everyone else. v30 didn't break Bitcoin. BIP-110 is the one that risks fracturing it over a culture war about data vs money. At this point I wouldn't retract it either, because it would just encourage small fringe UASF temper tantrums every time spammers find a new way to upload spam.