Bitcoin’s latest governance fight is not about price or ETF flows. It is about whether BIP-110 has real miner support, and Michael Saylor says the answer is no.
- Voluntary signaling is tiny. Reported support sits around 2.5%, far below the level needed to lock in this period.
- The proposal is restrictive. BIP-110 would temporarily limit several kinds of Bitcoin transaction data.
- The politics matter more than the code. The fight is over what Bitcoin should be used for, and who gets to decide.
- Later signaling may be forced. That makes “support” harder to read as genuine miner consensus.
According to an Aug. 1 analysis cited by crypto.news, Strategy Executive Chairman Michael Saylor says BIP-110 lacks miner consensus. Formally called the Reduced Data Temporary Softfork, it is not close to voluntary miner lock-in during the current difficulty period. At block 960, 561, Saylor counted 24 signaling blocks among 946, or 2.54%. By 11:13 UTC on Aug. 2, the public BIP-110 monitor had moved to block 960, 723 and showed 28 signals among 1, 108 blocks, or 2.53%.
The math is blunt. BIP-110 needs 1, 109 signaling blocks in a 2, 016-block difficulty period to lock in voluntarily. With only 908 blocks remaining at the time of the latest count, even perfect signaling from that point forward would not be enough to hit the threshold this period. Saylor called that result mathematically unreachable
and said the observed count was not miner consensus.
That distinction matters. “Voluntary signaling” is supposed to reflect real support from miners before a rule change becomes mandatory. In practice, pool policy, customer votes, and software defaults can blur the picture. A miner signal is not always a clean expression of political will. Sometimes it is just what the pool operator decided to do.
Saylor also alleged that the first 24 signals came from DATUM miners sharing rewards through OCEAN’s system. He went further and described the activity as a vertically integrated marketing campaign for Knots and OCEAN/DATUM.
That is Saylor’s accusation, not an independently verified fact, and it should be read that way.
BIP-110 is not a minor tweak hiding in a corner of the protocol. It proposes seven temporary consensus restrictions, lasting one year, aimed at limiting certain data-heavy Bitcoin transaction patterns. Among other things, it would:
- limit most new output scripts to 34 bytes
- cap OP_RETURN outputs at 83 bytes
- restrict certain data pushes to 256 bytes
- temporarily limit several Taproot-related features
For readers who do not spend their evenings decoding Bitcoin script, a quick translation helps. OP_RETURN is a transaction field used to attach data to the blockchain. Taproot is a Bitcoin upgrade that improved scripting flexibility and privacy. A soft fork is a rule change that tightens what counts as valid without forcing every older node to upgrade immediately. That sounds tidy. Bitcoin governance usually isn’t.
The proposal also includes UTXO grandfathering, which means outputs created before activation would remain exempt from the new restrictions. In plain English: old coins would not get trapped by the new rules just because the network changed around them. That is sensible compatibility work, even if it does nothing to settle the bigger argument.
And that bigger argument is the real story here. Supporters of tighter data limits argue that Bitcoin should be used mainly as money, not as a junk drawer for arbitrary data. Critics see a consensus-layer power grab dressed up as hygiene. Same blockchain, very different values.
The timing is important too. The current voluntary period ends at block 961, 631. From block 961, 632 through 963, 647, software enforcing BIP-110 would reject every block that does not signal bit 4. The proposal would then lock in at block 963, 648 and activate at block 965, 664, with the transaction restrictions beginning for 52, 416 blocks.
That mandatory signaling phase is where the optics get slippery. Once software requires a signal, a later 100% signaling rate does not necessarily prove broad, genuine agreement. It may simply mean the rules made non-compliance expensive or irrelevant. That is why Saylor’s warning lands: do not confuse forced compliance with real consensus.
Foundry USA Pool also asked its mining customers to vote on whether the pool should signal, with the voting window scheduled to close near block 961, 632. No verified public result was available by Aug. 2. That kind of setup is another reminder that “miner support” is often an umbrella term for several different kinds of decision-making, not one clean on-chain referendum from the gods.
The documentation angle adds more context, but not more certainty. crypto.news noted that the Reduced Data Temporary Softfork installation guide points users toward Bitcoin Knots and includes instructions for directing rented hashpower at a DATUM node. OCEAN’s DATUM documentation says miners create block templates through their local nodes while the pool coordinates reward splits. That shows a real technical relationship between the tools and the mining setup. It does not prove the stronger claim that the signaling is part of a coordinated marketing campaign.
Adam Back, the Blockstream co-founder cited in the reporting, also warned that pushing a change like this without broad agreement could divide the network. That concern is not absurd alarmism. Bitcoin can survive disagreement. It cannot survive people pretending disagreement does not matter.
What makes BIP-110 especially contentious is that it sits at the intersection of engineering and ideology. On one side is the argument that Bitcoin’s limited block space should be protected from unnecessary data bloat. On the other is the view that consensus rules should not be used as a blunt instrument to police what kinds of valid transaction data users may include. For Bitcoin, that is not a side issue. That is the fight.
The proposal itself makes its own case plainly. It argues that arbitrary data storage creates unnecessary burdens on node operators and distorts incentives away from Bitcoin’s role as money. It is a hard-line position, but at least it is honest about what it wants. The open question is whether the network wants it back.
Key questions and takeaways
-
What is BIP-110?
It is a proposed Bitcoin soft fork called Reduced Data Temporary Softfork that would temporarily restrict several kinds of data-heavy transaction behavior. -
Is voluntary miner support strong enough?
No. The reported signaling rate is around 2.5%, which is far below the threshold needed to lock in during the current difficulty period. -
Why is Saylor calling it “not miner consensus”?
Because the voluntary signaling numbers are very low, and he argues that later mandatory signaling would not reflect genuine miner agreement. -
What does BIP-110 actually change?
It limits several forms of transaction data, including script size, OP_RETURN output size, some data pushes, and certain Taproot-related behaviors. -
Why is the proposal controversial?
Because it is not just a technical tweak. It is a debate over whether Bitcoin should explicitly restrict non-monetary data use at the consensus layer. -
Could it split the network?
That is a risk, not a certainty. If most hashpower rejects the rules and enforcing nodes follow a different chain, a chain split becomes a real possibility.
Bitcoin governance rarely fails because of code alone. It fails when technical rules run headfirst into political reality. Right now, BIP-110 looks like a proposal with a clear purpose and weak voluntary support, which is a rough place to be when the whole point is consensus.
Further reading
A few more angles on the BIP-110 fight, for readers who want the receipts and the rebuttals.
- BIP-110 Cannot Reach Voluntary Lock-In
- 110 Reasons BIP 110 Is a Bad Idea
- Saylor says BIP-110 signals are concentrated in OCEAN
- Bitcoin BIP-110 Debate: Saylor Warns of Protocol Risks Amid
- Saylor Says Bitcoin’s Biggest Threat Is Internal Governance
- Bitcoin BIP 110 Faces Backlash as Back and Saylor Warn of
