The August Fork
Two separate August events keep getting lumped together. They are worth pulling apart before the arguments start.
Takeaway
BIP-110, a temporary soft fork, hits its mandatory-signaling window near block 961,632 (about 7 August) with almost no hashrate behind it. Separately, a Drivechain spinoff hard fork is being floated for late August. Different mechanisms, different risks; only the timing is shared.
BIP-110: The Soft Fork
A temporary, opt-in limit on how much arbitrary data a transaction can carry. It reaches its enforcement deadline in August.
THE DEADLINE
- Mandatory-signaling window near block 961,632 (about 7 August).
- Modified BIP9: a 55% threshold (1,109 of 2,016 blocks in one retarget period).
- Framed by its authors as a one-year temporary deployment that can be refined or extended.
WHERE SIGNALING STANDS
- About 0.31% of hashrate (~5 EH/s) as of late June; Ocean is effectively the only signaler.
- Knots, the main BIP-110-capable implementation, sits near 22% of nodes.
- No major pool has signaled.
CORE'S POSITION
Bitcoin Core ships no BIP-110 enforcement and no block-template support, reaffirmed in the Optech #411 Q&A. Enforcement today comes from Knots-family nodes.
SPEC STATUS
BIP-110 advanced to "Complete" in the BIPs repository, with test vectors and a generator script (PR #2201). "Complete" describes the document, not network adoption.
Signaling %, node share and projected heights move daily. Re-verify at meeting time.
The Drivechain Spinoff
A separate proposal, and a common point of confusion: BIP-300 is not the spinoff.
BIP-300 (DRIVECHAINS)
A long-standing soft fork proposal for hashrate-escrow sidechains: BTC is locked on the main chain and released by miner voting. It changes Bitcoin's rules but does not create a separate coin.
THE SPINOFF (HARD FORK)
Separately, Paul Sztorc / LayerTwo Labs have floated a hard-fork spinoff chain for late August (target near block 964,000, about 21 August):
- A new SHA-256d chain.
- A one-time difficulty reset.
- A 1:1 BTC airdrop to existing holders.
WHY IT MATTERS HERE
A spinoff launches a new chain rather than changing Bitcoin. It needs no Bitcoin consensus, but it lands in the same August window as BIP-110, which is why the two get conflated.
STATUS
This is a floated plan, not a scheduled event. Confirm the parameters and dates against a primary source before treating any figure as fixed.
Support And Opposition
The contested question is whether a low-threshold activation carrying little hashrate is safe.
THE AUTHORS' FRAMING
bip110.org presents BIP-110 as a modest, temporary measure: a 55% threshold, a voluntary deadline, and roughly a one-year deployment that can be refined or extended rather than a permanent rule change.
ADAM BACK
Argues BIP-110 "doesn't have tech nor ecosystem consensus", and that with minimal node and pool support the mandatory path either fails to activate or forces a minority split.
JAMESON LOPP
Calls the attempt "reckless" and warns the low 55% threshold "greatly increases the chances of a chain split".
THE MINORITY-CHAIN QUESTION
What happens if BIP-110 activates on minority hashrate: slow blocks, delayed coinbase maturity, and heavy exchange confirmation requirements. The June deck works through Murch's and Lopp's analysis in detail.
The Data-Carrier Backdrop
BIP-110 targets arbitrary data in transactions. How much is there, and does a transaction-count view undercount it?
HOW MUCH DATA
Blockspace Weekly #29 ("Counting the Leaves", Renaud Cuny, June) reports Alkanes protostones are about 91% of OP_RETURN outputs (~2,540 per block), and that the OP_RETURN share of block space roughly doubled from 13% to 34% over twelve months.
WHY TX COUNT MISLEADS
The analysis argues BIP-110's 256-byte witness limit is aimed at the roughly 627 code-deployment transactions that bootstrap an estimated 19 million downstream mints. Judging the limit by raw transaction volume misses those leverage points.
Figures from a single community analysis; treat as one data point, not a consensus measurement.
A Counter-Proposal: Segregated Data
Instead of restricting data carriage, give data a prunable home of its own.
THE IDEA
MrHash's "Segregated Data" draft (Delving Bitcoin, June) proposes a prunable, script-isolated region of each block for data carriage, so nodes can drop it without affecting the UTXO set.
HOW IT WORKS
- A separate coinbase Merkle commitment for the data region.
- Witness-v2 reference outputs pointing at the data.
- A 288-block retention window, after which the data can be pruned.
PUSHBACK
Pieter Wuille pushed back, describing the reference outputs as "weight markers". The proposal reframes the debate from policing data toward finding it a cheaper, prunable place to live.
Watching Fork Day
The operator-side complement: if a split happens, observe it cleanly rather than guess.
THE MONITORING PLAN
b10c's BNOC fork-monitoring notes lay out a plan for fork day:
- A side-by-side fork-observer instance tracking both chains.
- Replay tracking across the split.
- Pool alignment inferred from Stratum data.
REPLAY-IMMUNE UTXOs
murchandamus proposed cataloguing replay-immune, Bitcoin-only UTXO sets in advance, so wallets and services can move coins on one chain without the transaction also being valid on the other.
Discussion
If the threshold is unreachable, what is the deadline actually forcing?
QUESTION
If BIP-110 activates at low hashrate, what happens to blocks, exchanges and confirmation times on each chain?
QUESTION
Is a limit on data carriage the right tool, or does a prunable region like Segregated Data address the concern more cleanly?
QUESTION
The spinoff hard fork needs no Bitcoin consensus. Does landing in the same August window change how either event plays out?
OPEN ISSUE
Two events in one compressed window raise replay and chain-split questions; the monitoring plan is the operator-side answer.