Bitcoin nears the deadline for BIP-110, a proposed temporary soft fork that would shrink block data. Once the current signaling period ends, nodes enforcing it will reject blocks that do not signal support.
A third-party monitor showed only 48 of 1,831 blocks signaling as of 14:41:49 UTC on Aug. 7, just 2.62%, with 185 blocks left before the period closes.
BIP-110 requires 1,109 signaling blocks in a 2,016-block period to meet its 55% threshold. Even if every one of those 185 remaining blocks signaled, the period would finish at 233 of 2,016, or about 11.56%.
Different rules at height 961,632
From height 961,632, continuously enforcing BIP-110 nodes reject blocks that do not signal bit 4. Nodes following existing Bitcoin rules may accept the same blocks if they otherwise satisfy those rules.
The result can be divergent block acceptance, while any sustained enforcing branch depends on miners producing BIP-110-valid work after the boundary.
Under the proposal, mandatory signaling runs through block 963,647, lock-in won’t happen once the height reaches 963,648, and the reduced-data rules activate at 965,664. That schedule governs BIP-110-enforcing nodes without binding every Bitcoin participant.
The 2.62% reading measures version bits in observed blocks, and the monitor says it sources block data from mempool.space and checks each block’s version field for bit 4.
A BIP-110 implementation pull request in the Bitcoin Core repository closed unmerged on March 26. Core contributor Antoine Poinsot wrote in a personal capacity on June 4 that Core does not enforce the proposal.
Mining pool OCEAN announced separate signaling and non-signaling endpoints and said its default would switch on July 15. Confirming that the switch actually took place and that every miner using the pool now enforces BIP-110 would require independent verification.
Alternative Bitcoin node implementation Bitcoin Knots used its Aug. 7 release to warn that older non-enforcing software, explicitly including current Bitcoin Core, could stop fully validating BIP-110 rules and leave chainstate unsafe in some scenarios.
Independently reproducing the Core-specific warning on Bitcoin Core or on mainnet remains outstanding.
A July 17 BlockSlop technical write-up reproduced a narrower late-upgrade problem on regtest using enforcing and non-enforcing Knots builds. A data directory could retain a block accepted under the old rules after the operator switched builds because normal startup did not reconnect the inherited history. The test left out physical database corruption or a mainnet incident.
Knots then merged a safeguard that scans inherited headers for mandatory-signaling violations, invalidates offending blocks, and reorganizes. Transaction or script violations that are not visible in headers still need reconnection validation and can require reindexing.
The first blocks after height 961,631 will reveal which miners change signaling and whether an enforcing chain accumulates work. Measuring economic support would take separate evidence, such as exchange listings, node adoption data, or holder behavior.