Bitcoin's anti-spam change has zero miner support. The veto is the story.
BIP-110 tried to make data censorship easier to activate. The network's answer, so far, is that no one wants their fingerprints on it.
CryptoVibe Desk · bitcoin · bip-110 · consensus
- →BIP-110 would cap OP_RETURN data and block most arbitrary data chunks above 256 bytes for one year.
- →Miner signaling stood at 0% as of July 12, while node adoption sat in the low single digits, per CoinDesk.
- →Watch the early August lock-in block because weak support would create a minority chain, not a Bitcoin rule change.
- OP_RETURN → OP_RETURN is a Bitcoin transaction field that lets users attach small pieces of extra data.
- soft fork → A soft fork is a rule change where upgraded nodes reject some transactions that older nodes still see as valid.
- UASF → A user-activated soft fork is when nodes enforce a new rule even without broad miner agreement.
- miner signaling → Miner signaling is how mining pools show support for a proposed Bitcoin rule change inside mined blocks.
BIP-110 is failing at the voting layer. CoinDesk reported on July 12 that miner signaling sat at 0% in the current period. It had never passed about 1% in any earlier period.
That matters more than the spam fight. BIP-110 would cap OP_RETURN back to its old small size. It would also block most arbitrary data chunks above 256 bytes for one year. The target is obvious: Ordinals, inscriptions, and token schemes that use Bitcoin as a data store.
The code path is a user-activated soft fork. Nodes running BIP-110 would reject blocks that don't signal support after lock-in. The proposal still added a 55% miner-signaling threshold, far below the usual 95% bar. According to CoinDesk, it can't clear even that.
At the contract level, this is not about payments versus pictures. Bitcoin doesn't have contracts in the Ethereum sense, but it does have consensus rules. BIP-110 would make some currently valid, fee-paying transactions invalid. That is a bigger move than changing relay policy.
Michael Saylor opposed the proposal on July 11. His argument was simple: a spam dispute should not become a consensus change. Adam Back also opposed it, saying supporters can fork away if they want, but Bitcoin won't join them.
If you're holding bitcoin, this is the part to care about. A few percent of nodes and zero miners do not move the network. They produce a minority chain that most users, wallets, and exchanges can ignore. That's the catch with opt-in consensus. It protects Bitcoin from bad upgrades, but it also gives every serious soft fork a social veto.
The data-congestion concern is real. Blocks have carried more non-financial data since an October update. Reasonable people can think that is ugly. But ugliness is not the same thing as a consensus bug.
BIP-110's collapse confirms it officially. Lowering the activation threshold to 55% doesn't help if no major pool wants to endorse data censorship. Bitcoin's upgrade process is not a governance dashboard. It is thousands of operators deciding what code they will run.
The proposal's deadline lands at block 961,542, expected in early August 2026. If nothing changes before then, BIP-110 won't be a Bitcoin upgrade. It will be a clean test of how small a fork can be before everyone stops pretending it matters.
BIP-110 proponents' choice to push a 55% UASF was reckless because it turned a block-space policy fight into a visible minority-chain threat with no mining base.
By block 961,542 in early August 2026, watch whether any major mining pool starts signaling BIP-110. If support stays below 5%, the fork is functionally dead.
Primary links and supporting reads used by the desk for this story.
Forward this.
