Ripple CTO Emeritus Breaks Down Bitcoin Forks: ‘Why Else?’

Ripple CTO Emeritus David Schwartz recently weighed in on an X conversation, explaining the logic behind Bitcoin hard forks in the process.

An X user had questioned the value of a new PoW fork, citing Bitcoin Cash and the most recent BIP-110 proposal. While forks can address “surface” issues, such as whether a network has too much or too little spam, they still end up inheriting the underlying governance issue, the X user argued.

“My point here is that if you believe that the old chain has been captured, how does creating a new PoW fork help? Yes, it will have the feature you wanted, but at some point in time, if your new chain becomes super popular, it will get captured once again,” the X user added.

Schwartz’s perspective on a PoW fork is quite different, saying that it gives participants the ability to choose between competing sets of rules.

“The point of the fork is to let everyone get what they want by choosing which side of the fork they want to interact with,” Schwartz said. “If people on the losing side come to the winning side, it’s because they realize that the winning side’s rules produce the results they prefer. Why else?” Schwartz asked.

This implies that if participants strongly disagree with the rules of an existing network, a fork can give them another option. If that alternative eventually becomes more attractive, users can migrate toward it.

Bitcoin soft fork faces setback

Last Saturday, a new minority chain created when BIP-110 supporters split from Bitcoin lasted just two blocks.

BIP-110, formally the Reduced Data Temporary Softfork, was the brainchild of pseudonymous developer Dathon Ohm with input from Luke Dashjr, creator of the Bitcoin Knots node software. It called for a one-year consensus-level restriction on arbitrary data in Bitcoin transactions. This includes Ordinals inscriptions (Bitcoin’s answer to NFTs), BRC-20 and Runes (both fungible token standards), and oversized OP_RETURN.

The proposal contained seven rules capping most outputs at 34 bytes, OP_RETURN at 83 bytes, and data pushes at 256 bytes, plus restrictions on Taproot annexes and control blocks.