Farside Investors’ new BIP-110 signaling alerts have put Bitcoin’s arbitrary-data dispute on a live deadline, giving exchanges, wallets, miners, pools, and node operators a concrete August window to plan around even while miner signaling remains low.
A July 3 Farside post reported a new BIP-110 signaling block and listed 7 signaling blocks in the current period. Farside’s Q&A says its X account will post automatically each time a BIP-110 signaling block is produced.
Miner support remains minimal. BGeometrics’ daily API, retrieved July 3 and current through July 2, shows 38 BIP-110 signaling blocks out of 9,066 total blocks since May 1, or 0.42%.
Over the latest seven-day window in the API, June 26 through July 2, the count was 8 out of 1,000 blocks, or 0.8%.
The activation design creates the deadline even while current miner support remains low. BIP-110 has a miner threshold, a mandatory-signaling fallback, and a defined activation path.
The public feed moves those mechanics from forum argument into infrastructure planning before the August window arrives.
Public alerts put tiny support into view
BIP-110 remains far from miner-driven lock-in while producing enough signals to create a public record.
Current signaling data puts the campaign far below lock-in: 38 of 9,066 blocks since May 1 through July 2, or 0.42%; 8 of 1,000 blocks in the latest seven-day API window, or 0.8%; 1 of 143 blocks on July 1, or 0.70%; and 2 of 131 blocks on July 2, or 1.53%. Miner lock-in requires 1,109 of 2,016 blocks, or 55%, in a difficulty adjustment period.
The July 3 Farside alert’s 7-block period count is best treated as a snapshot unless paired with the number of blocks already elapsed in that retarget period. At the 1,109-block lock-in threshold, 7 signals would still require 1,102 additional signaling blocks before the period closes.
The gap keeps near-term miner activation remote. It also gives the alerts a practical role: every new signal can now be compared with the 55% threshold and with the mandatory-signaling calendar.
BGeometrics said in its June 10 background note that its daily dataset showed zero signaling blocks from May 1 through about May 20, followed by low activity around May 21. It said observed volumes looked consistent with individual miners or smaller operations, with no visible commitment by major pools, and noted that Bitcoin Core had not endorsed BIP-110.
A large-pool move would change the data quickly. BGeometrics pointed to Foundry USA and Antpool as the kinds of pool decisions that could move daily signaling from low single digits into a more meaningful range within days.
Until then, the miner lock-in route remains remote, while the public alert feed keeps the campaign visible.
For an exchange, wallet, pool, or node operator, the decision is whether to wait for a bigger signal or build procedures while the signal is still small. Each alert becomes part of a public record that customers, counterparties, and market infrastructure teams can track.
The August window turns support data into operational risk
The BIP text defines the deployment as reduced_data, using version bit 4. Miner-driven lock-in requires 1,109 of 2,016 blocks, or 55%, to signal during a difficulty adjustment period.
The same specification defines a mandatory-signaling period from blocks 961,632 to 963,647, with lock-in no later than height 963,648 and activation one retarget period later at height 965,664.
The BIP-110 site presents that as an August mandatory-lock-in window followed by roughly two weeks before activation, then about one year of active restrictions. The BIP text describes a 52,416-block active duration, after which the rules expire.
For operators, those mechanics carry more weight than the ideological dispute itself. During mandatory signaling, the BIP says blocks that do not signal bit 4 are rejected as invalid by enforcing nodes.
If the deployment becomes active, enforcing nodes apply the new consensus restrictions for the active period.
Exchanges need deposit, withdrawal, confirmation, and chain-risk policies for a contentious activation path. Wallet teams need Taproot and Miniscript compatibility checks because the BIP text says the Miniscript compiler would need changes if the proposal activates and acknowledges very unlikely scenarios in which funds could theoretically be frozen or lost.
Mining pools need a clear version-bit policy. Node operators need to know whether their software is enforcing BIP-110 rules and how that affects block validity during the mandatory-signaling window.
Those decisions can be made while treating activation as uncertain. A consensus dispute with public alerts and fixed block heights can create operational demands before support appears large.
CryptoSlate has already covered the broader fork-risk setup, including Bitcoin being less than 10,000 blocks from the BIP-110 deadline in June and earlier node-support questions around the anti-spam proposal.
Live public alerting now sits on top of the activation design, shifting the audience from developers and policy combatants to infrastructure teams that monitor operational thresholds.
Readiness costs rise even when signaling remains small. If support stays near current levels, BIP-110 remains a loud but weak activation campaign headed toward the mandatory-signaling window.
If a major pool starts signaling, the market’s assessment changes quickly because the path to 1,109 blocks per period becomes less theoretical. If exchanges, wallets, or large node operators publicly reject or prepare for the proposal, those statements may carry as much weight as block headers because a contentious soft fork depends on economic coordination.
For now, the numbers point to a small campaign with a large calendar problem. BGeometrics’ latest daily data ends on July 2 with support still far below the miner threshold.
Farside’s July 3 alert shows the signal continues to appear. The clearest change would be identifiable large-pool behavior or concrete readiness statements from the infrastructure that would have to live with the result.
