Ripple’s Former Chief Technology Officer Says Defeat in BIP-110 Vote Does Not Warrant Creating Separate Blockchain

A dispute over Bitcoin’s failed BIP-110 fork proposal has surfaced a core disagreement about when network disagreement becomes an attack. David Schwartz, Ripple’s CTO emeritus, argues that launching a separate chain after losing a consensus vote crosses from governance into hostile action, a position rejected by fork supporters.

• BIP-110 chain went live at block 961,640 with BLAKE2b replacing SHA256d mining algorithm
• The fork had previously stalled after backing pool Roughnecks produced only two blocks before failing
• Dispute centers on whether losing a governance vote justifies creating a new Bitcoin chain or constitutes network attack

• 961,640 Block height where BIP-110 chain went live with new mining algorithm
• 2 Total blocks produced by Roughnecks pool before initial BIP-110 branch stalled
• 164 Bytes added to block header in BIP-110’s redesigned structure
• ~300 KB Block size cap under temporary rules running until September 2027

The dispute intensified on August 31 when Schwartz engaged with fork advocate loogart over whether launching a separate proof-of-work chain after a failed governance vote constitutes an attack on Bitcoin. Schwartz drew a line between participating in governance, which he accepts, and attacking the network, which he says begins when participants refuse to accept a lost consensus vote and proceed anyway.

Schwartz distinguishes between Governance and network attack

Schwartz told loogart directly: “You switched from participating in governance to attacking when you refused to accept that you lost.” His core argument holds that inventing language to justify continued action after losing a vote moves beyond good-faith disagreement into what he characterized as attacks and lunacy.

Loogart countered that their group accepted defeat and simply continued their version of Bitcoin elsewhere without forcing others to follow.

Schwartz rejected this framing, arguing that the group’s post-hoc justifications conflate accepting a loss with accepting the outcome. He added, “I’m not arguing that you are incapable of pretending you have good faith disagreement over governance. I’m arguing that there’s lots of evidence that when you do so, you are pretending.” The XRP Ledger architect’s position reflects a technical view that consensus mechanisms require accepting unfavorable results, not merely the option to create alternatives.

This debate reflects deeper questions about Bitcoin’s governance model, which lacks formal voting mechanisms present in other blockchain projects. Bitcoin instead relies on rough consensus among developers, miners, and node operators, with acceptance determined through which software implementations achieve widespread adoption. The absence of explicit governance structures means disagreements over protocol changes cannot be definitively resolved through voting, creating persistent tension when different factions prefer different technical directions.

Technical changes in BLAKE2b swap include block header redesign

The BIP-110 chain’s flag-day hard fork replaced Bitcoin’s SHA256d mining algorithm with BLAKE2b and introduced a 164-byte block header alongside temporary rules capping block size at roughly 300 kilobytes until September 2027. Bitcoin Knots developer Luke Dashjr defended the changes on August 30, arguing that BLAKE2b eliminates SHA256d’s known weaknesses including ASICBoost vulnerability.

Dashjr also contended that the redesigned header closes a block-withholding loophole previously caught only through miner monitoring.

The technical case for change centers on perceived security improvements rather than capacity expansion. However, Dashjr faced separate consequences for his advocacy, having been removed as an editor of Bitcoin’s improvement proposal repository over what was described as a conflict of interest in his handling of BIP-110.

From a mining perspective, switching algorithms represents a significant undertaking requiring hardware manufacturers to develop new application-specific integrated circuits (ASICs) optimized for BLAKE2b. This technical requirement creates a barrier to adoption by limiting the existing mining infrastructure that could immediately participate on the new chain, which partly explains the difficulty BIP-110 faced attracting hashpower.

Original fork failed to gain miner support before chain split again

The BIP-110 chain had already stalled before the latest split, having forked from Bitcoin’s main chain at block 961,632 after failing to attract sufficient mining support. The backing pool Roughnecks produced only two blocks before the branch stalled while Bitcoin’s main chain continued at normal pace, creating a gap of several hundred blocks within weeks.

This initial failure underscored deep disagreement within Bitcoin’s mining ecosystem over the proposal’s merits.

The underlying tension traces to Bitcoin Core’s decision to remove its limit on OP_RETURN data, which allowed non-monetary content including Ordinals and Runes to fill blocks that BIP-110 supporters wanted reserved for transactions. That technical decision fractured Bitcoin’s online community into opposing camps, with one X user calling BLAKE2b hostile in the manner of Bitcoin Cash and Bitcoin SV, while another framed BIP-110 as fixing bugs introduced by Taproot rather than attacking Bitcoin.

Bitcoin has experienced previous contentious forks, most notably the 2017 split that created Bitcoin Cash over disagreement about block size limits. Those precedents demonstrate that when consensus breaks down, some participants will pursue alternative chains, establishing a pattern that now informs the BIP-110 debate. Industry observers note that each contentious fork weakens the winning chain’s network effects by dividing developer talent, mining hashrate, and user adoption across competing versions.

The outcome remains contested: neither Schwartz’s position that the fork constitutes an attack nor the fork supporters’ claim that launching a separate chain represents legitimate governance has achieved consensus within Bitcoin’s developer and user base, and disagreement over whether future failed governance votes justify new chains will likely persist as a precedent.

BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.