At around 19:35 UTC on Saturday, Bitcoin reached block 961,632 and a soft fork that almost nobody in mining wants entered its mandatory-signalling window. Miner support has seldom exceeded 2.5%, against a 55% activation threshold. Every outlet is now asking whether the fork will happen. That is the least useful question available, because the probable answer is barely, if at all — and the fork's likely failure is precisely what creates the risk to ordinary holders.
A soft fork with real support activates cleanly and everyone upgrades. A soft fork with under 3% support that forces its way into an activation window anyway produces the worst configuration available: a chain that may briefly exist, coins that may be worth nothing, and no automatic replay protection for roughly a month. That combination is a trap, and it is open right now.
An activation path that does not require agreement
BIP-110 is a proposal to temporarily keep images, text and other non-payment data out of Bitcoin transactions for a year. Changing Bitcoin's rules normally requires miners to agree, and they register that agreement by marking the blocks they produce. BIP-110 needs 1,109 marked blocks out of a 2,016-block stretch — 55%. That route is closed and has been for weeks.
But the proposal has a second route written into it. From block 961,632, nodes running BIP-110 software reject any block that does not carry the mark, whether miners agreed or not. Supporters call this a user-activated soft fork: the rule change is forced by node operators rather than by hash power. They point to the 2017 activation of SegWit via BIP-148 as precedent, when users pushed through a change miners had not delivered.
The immediate consequence is unusual. Almost every block being mined right now does not carry the mark. So the nodes enforcing BIP-110 are, as of this weekend, rejecting the chain that essentially all of Bitcoin's mining power is building. Prominent figures including Strategy chairman Michael Saylor and Blockstream chief executive Adam Back have publicly opposed the proposal, which is part of why signalling stayed where it did.
Why the likely outcome is the dangerous one
If some miners keep building a BIP-110-compatible branch while the rest mine as usual, two competing versions of the transaction history can emerge. If nobody extends the minority branch, it simply stalls. With signalling near 2.6% on trackers as of Friday, a minority branch would produce blocks very slowly or stop advancing altogether. Node share, it is worth stressing, is not the same thing as mining power — a large count of enforcing nodes does not produce blocks.
So a split is possible rather than certain. That ambiguity is the problem. A clean failure would be harmless: nothing forks, nothing to sell, nothing to exploit. A clean success would also be manageable: everyone upgrades, one chain continues. The in-between state — a branch that exists just enough for someone to quote a price on its coins — is where holders get hurt.
The replay trap, drawn step by step
If a split occurs, everyone holding bitcoin ends up holding the same balance twice, once on each chain. The second copy may be worth very little or nothing at all. Someone will still offer to buy it, possibly at an unusually attractive price. It looks like free money.
Take the deal, and the buyer can take real bitcoin as well. Both chains initially accept identical transactions. A transaction signed to send the fork coins can also be broadcast on Bitcoin itself, and the buyer receives the same amount in actual BTC at the same destination. This is a replay attack.
The precision here matters, because imprecision is what makes safety advice ignorable. A replay does not drain a wallet. Only the coins actually put up for sale move. They leave as real bitcoin rather than the fork version, with a transaction fee paid on both chains. Someone who sells a small amount loses a small amount. Someone who sells a large position loses a large one — which is why Bitcoin developer Kevin Loaec, who flagged the risk on X on 6 August, said large holders would likely be targeted first.
The safe default is to do nothing. Coins that never move cannot be replayed, because there is no signed transaction to copy. If you hold BTC in self-custody and you are not confident you can separate two balances across two chains, the correct action this month is no action at all.
Separating the balances is harder than usual here because BIP-110 provides no automatic replay protection. The fork's own restrictions on transaction data — the rules that would eventually make the two chains diverge and stop accepting each other's transactions — do not switch on until block 965,664, which CoinDesk placed roughly four weeks out from Saturday, or around the start of September. Until then, a holder who wanted to sell safely would need to deliberately create coins that exist on only one branch before spending. That is an expert operation, not a wallet button.
Timing across all of this depends on how fast blocks are found, so the specific dates move by a day or so in either direction. The window, not the calendar, is the thing to track.
The governance bug
Strip out the specifics and a general point remains: an activation mechanism that can fire without consensus is a governance bug, not a governance feature. BIP-110's mandatory-signalling clause was designed to give node operators leverage over miners. What it actually does at 2.6% support is create a several-week period in which the protocol has neither agreed to change nor cleanly declined to, and in which the two possible chains accept each other's transactions.
That gap was a design choice. Replay protection could have been active from the first block of the activation window rather than roughly four weeks later. A contested upgrade built defensively would separate the chains at the moment of divergence, define an explicit failure condition, and specify what happens when the threshold is plainly not met. BIP-110 does none of those things, and the cost of that is paid by holders who did nothing except respond rationally to what looks like an airdrop.
On the underlying dispute, reasonable people disagree and this piece takes no side. Supporters argue that arbitrary data storage crowds out payments and erodes Bitcoin's function as sound money, and that a temporary limit is a proportionate correction. Critics argue that the limits amount to censorship of otherwise valid transactions, are trivially circumvented, and are not worth a chain-split risk. Both cases are coherent.
The safety advice does not depend on who is right. Whatever you think of data limits, the mechanism by which this particular proposal is trying to activate has left a live replay window open, and the only free action available to a non-expert holder is to sit still until it closes.