Bitcoin rejected a proposed transaction limit. The next fight is who writes the rules.
BIP-110 failed the activation test, but the proof-of-work talk matters because it changes the question from miner support to rule ownership.

CryptoVibe Desk · bitcoin · bip-110 · consensus

- →BIP-110's enforcing branch reportedly made two blocks after block 961,632, then stalled at height 961,633.
- →The mechanism worked as a rejection filter: BIP110monitor showed 0 of 267 signaling blocks on August 10.
- →Watch the proof-of-work talk next, because that would move this from soft-fork failure to breakaway-chain politics.
- BIP → A Bitcoin Improvement Proposal is a written plan for changing Bitcoin's rules or related software.
- soft fork → A soft fork changes the rules so upgraded nodes reject some blocks that older nodes may still accept.
- signaling → Signaling is how miners show support for a proposed rule change inside the blocks they mine.
- proof of work → Proof of work is the mining system that decides who can add the next valid Bitcoin block.
BIP-110 got two blocks, then stopped.
That is the cleanest version of the story. Bitcoin Magazine reports that BIP-110's enforcing branch split from the main Bitcoin chain at block 961,632. It then produced only two blocks before stalling at height 961,633. The proposal was called Reduced Data Temporary Softfork, and it would limit several transaction data fields for one year.
The failed fork matters because Bitcoin's activation process worked. BIP-110 needed 55% support, or 1,109 of 2,016 blocks, according to the BIP text. BIP110monitor showed only 51 of 2,016 blocks signaling in the prior period as of August 10. In the current period, it showed 0 of 267 blocks.
That is not a close vote. That is rejection by the actual rule path.
This is not really about whether you like arbitrary data in Bitcoin transactions. It is about who gets to turn a preference into a consensus rule. BIP-110 tried to use miner signaling as the path, and miners did not follow. If you're reading this as a user, your node did not need a press release.
The tradeoff was simple: cleaner block space for rejecting some currently valid transactions. That is never a small ask. Even a one-year deployment changes what miners may include, what wallets may send, and what relay policy starts to resemble.
This is where the proof-of-work discussion changes the story. CryptoSlate reports that some BIP-110 supporters are discussing a proof-of-work change. A soft fork says the existing system can tighten rules if enough of it agrees. A proof-of-work change says the current miners said no, so the mining game may need replacing.
Read the mechanism, not the thread. The mandatory-signaling window ran from blocks 961,632 to 963,647, per BIP110monitor's August 10 API readout. The fork reportedly stalled almost immediately inside that window. The only number that matters is the current 0% signaling print.
The OCEAN detail is still based on reports. The Defiant says OCEAN refunded roughly 0.3 BTC after the effort stalled. That may explain the local failure path, but it does not change the protocol result. A rule change that cannot keep miners on its branch is not activated Bitcoin.
The sharper test comes next. A failed soft fork can remain a failed proposal. A proof-of-work change turns it into a claim about legitimacy. Bitcoin has seen this pattern before in block-size fights.
BIP-110 did not prove that Bitcoin cannot change. It proved that this change did not clear the current activation path. That is boring in the best technical sense. The system rejected a contested rule without needing a committee to say no.
BIP-110 backers turning to a proof-of-work change would be an admission that miners rejected their soft fork, because the existing activation path already gave them a direct vote.
By the end of September 2026, watch whether BIP-110 supporters publish working proof-of-work-change code and a launch height, not just forum posts.
Primary links and supporting reads used by the desk for this story.
Forward this.











