290 blocks. That's the number Dathon Ohm reportedly put on the clock before Bitcoin miners would be forced to signal support for BIP-110. If the math holds, that is roughly 48 hours. In that window, miners who do not coordinate their version bits would see their blocks treated as invalid and discarded. In that same window, they are being told to abandon Bitcoin Core, switch to Bitcoin Knots, and treat Core as 'unsafe.'
I had to reread that twice.
This is not the cadence of a normal Bitcoin upgrade. It is the cadence of an ambush. And in a bear market already full of dread, an ambush dressed as a soft fork can do more damage than a chain split itself. The first question clients will ask us this week is simple: 'Is my bitcoin safe?' The honest answer is that the bitcoin protocol itself is safe, but the social layer around it is being stress-tested by a 48-hour deadline.
Context: What BIP-110 Actually Is
Let me be clear about what BIP-110 actually is. It is a real historical proposal from Gavin Andresen, formally called P2SH Version Check. It was designed to force a version bit in Bitcoin's block header to make sure certain legacy P2SH script rules were actually being enforced. In the language of protocol nerds, it is a soft-fork style version bit activation. In the language of normal humans, it is a small consensus rule adjustment. It does not change the 21 million supply cap. It does not change block rewards. It does not change the halving schedule. It does not invent new cryptography. If BIP-110 were activated in a boring, transparent way, it would barely make headlines.
But the version of the story now circulating is not boring. It has a date. It has a scapegoat. And it has a client-switching demand.
Bitcoin's consensus rules are not enforced by an authority. They are enforced by every full node that chooses to accept a block. When someone says a miner's block will be 'invalid,' they mean it will be invalid for nodes running the new enforcement logic. Nodes that have not upgraded will still see that same block as valid. That is the fundamental fact that makes a 48-hour version-bit ultimatum so strange. It only works if the majority of economic nodes and miners have already adopted the new rule. If they have, you don't need an ultimatum. If they haven't, the ultimatum is just a threat.
Normal soft-fork activation is built around this reality. BIP-9, the VersionBits framework, gives miners a signaling window that is measured in retarget periods, not in hours. Bitcoin's most contentious recent activation, SegWit, took months of public debate, miner coordination and eventual compromise through BIP-91 and BIP-148. A user-activated soft fork is designed to give users a warning date far in advance so exchanges, wallets, and mining pools can prepare. BIP-148 had a months-long countdown. BIP-110, as described here, has 290 blocks. That is the difference between a coordinated upgrade and a coordinated ambush.
The comparison table is almost too clean to be accidental. BIP-9 activation uses miner signaling over multiple retarget periods, usually months. BIP-148 used a user-set date, still months away, to force a decision. This BIP-110 announcement uses an individual's public statement as the trigger, gives miners 48 hours to obey, and asks them to install a non-Core client. That is not how soft forks have ever been executed in Bitcoin's history. It is how a mutiny is announced.
Core Analysis: Why 48 Hours Is Not a Soft Fork
Let's look at the operational details that matter.
First, mining pools cannot simply flip a bit and move on. Version bit signaling is embedded in the block header, but it has downstream consequences. Pool software must be updated, tested, and deployed. Node infrastructure must be swapped. Monitoring dashboards need to be pointed at the new client. Transaction selection policies may differ between Bitcoin Core and Bitcoin Knots. If a pool makes a mistake under the pressure of a 48-hour deadline, it risks orphaning its own blocks and losing coinbase revenue. That is not a hypothetical risk. It is exactly how a small technical upgrade becomes a financial bloodbath.
Second, the demand to switch from Bitcoin Core to Bitcoin Knots is not a neutral security recommendation. Bitcoin Knots is a serious client, maintained by Luke Dashjr, but it is not Bitcoin Core. It is a fork of Bitcoin Core with a different governance and review culture. There is nothing wrong with running it in ordinary circumstances. But telling every miner to switch clients in 48 hours because Core is 'unsafe' requires evidence. What vulnerability? What attack path? What is the bug? Without a patch, a CVE, or a reproducible exploit, 'Core is unsafe' is not a technical alert. It is a commercial migration disguised as emergency maintenance.
I have spent enough years in this industry to recognize the pattern. First you create a sense of urgency. Then you supply a ready-made solution. Then you ask people to move their infrastructure into that solution before they have time to ask too many questions. This pattern predates Bitcoin, and it will outlive every bear market.
Third, the timeline does not fit the consensus process. If BIP-110 were a genuine fix for an urgent vulnerability, the correct response would be to release a patched Bitcoin Core, give the whole ecosystem time to update, and let the normal activation process do its job. If BIP-110 were a legitimate soft fork, it would be discussed on the Bitcoin development mailing list, reviewed by multiple client teams, and signaled by miners over multiple retarget periods. A 290-block window is not enough time for even a small fraction of the global mining community to coordinate. It is enough time to create chaos and then point at the chaos as evidence of disorder.
I was sitting in the exchange seat during the 2017 fork debates. We needed weeks to build split-bucket contingency plans, test replay protection scenarios, and coordinate with wallet teams. The idea that a version-bit enforcement with a 48-hour escape window could be safely absorbed by the ecosystem is not a technical argument. It is a stress test designed to see who blinks first.
Market Impact: Fear Priced Before Blocks Are Orphaned
I also want to address the market angle. Surprise fork threats are almost always repriced as risk events. In the past, when a contentious activation appeared to move forward with a hard deadline, BTC volatility spiked and exchanges prepared for split-bucket scenarios. The market does not need to know whether a fork will actually happen; it only needs to know that a fork is possible. Option markets react faster than block headers. A 48-hour deadline gives traders very little time to hedge, which usually means they sell first and analyze later. In a bear market, survival matters more than gains. That is why the announcement, if taken seriously, could trigger a defensive round of selling before a single block is orphaned.
But here is where I want to be honest about uncertainty. The original report, as parsed, lacks a year. It lacks a link to the actual announcement. It lacks confirmation from mining pools, exchanges, or other Core contributors. That makes it hard to dismiss, but also hard to verify. If this is an old event from the 2015-2017 block-size wars, then much of this story is historical noise. If it is happening now, it is either misinformation or an extreme governance attack. Both are dangerous in different ways. The absence of verifiable context is itself a red flag.
The Contrarian Read: The Client Is the Message
The contrarian read is not that BIP-110 is good or bad. The contrarian read is that BIP-110 is the wrong headline. The real story is a small group trying to move protocol governance by changing the default mining client, not by changing the code. BIP-110 is a deliberately boring maintenance proposal. It has no new cryptography, no supply shock, no elegant mechanism. It would never be a reason for a miner to run from Core to Knots in two days. The only reason to attach BIP-110 to a 48-hour ultimatum is to borrow legitimacy from the BIP process while bypassing the consensus process.
The deeper danger is the precedent. If miners learn that they must comply with an announced deadline or be 'invalidated,' then every future disagreement can be weaponized the same way. You do not need 95% signaling. You do not need broad node consensus. You just need a loud announcement, a small client fork, and enough fear to move hashrate. That is a form of governance by social engineering, and it is far more corrosive to Bitcoin than any P2SH edge case.
I don't regret the dance with contentious upgrades in my 2017 days. That era taught me how quickly community panic becomes price action. But this dance is different. It asks miners to make an irreversible operational choice in the time it takes to brew a few pots of coffee. And it frames that choice as simply a question of which software to click, when the real question is who gets to define consensus.
Takeaway: Watch the Next 290 Blocks
So what should we watch in the next 290 blocks? First, public statements from major mining pools. Second, hashrate distribution by client, if any pool shares that data. Third, exchange announcements about deposit risk or fork-split contingency. If major pools quietly ignore the deadline, this event becomes another footnote in the long history of Bitcoin FUD. If they switch clients and start signaling in the required version bit, we are not watching a soft fork. We are watching a takeover attempt by deadline.
Volatility isn't just the price chart. It's the market's best measurement of whether Bitcoin's social contract still holds. Right now, that contract is being tested with a countdown clock. I plan to watch the blocks, not the tweets. And I will not be rushing to change my client until someone shows me the exploit.