Bitcoin's data-ban proposal is almost out of miners. August now looks like a formality.
BIP-110 still has an activation path on paper. The chain support needed to make it real is missing.
CryptoVibe Desk · bitcoin · bip-110 · miners
- →BIP-110 would temporarily restrict some non-payment data on Bitcoin, but miner signaling sat below 1% on July 18.
- →The proposal needs 55% of blocks in one 2,016-block period, so the numbers don't add up for activation.
- →Watch the early August mandatory-signaling window, where enforcing nodes could reject non-signaling blocks and expose minority-chain risk.
- BIP → A Bitcoin Improvement Proposal is a formal document for changing or documenting how Bitcoin works.
- soft fork → A soft fork tightens Bitcoin's rules, so upgraded nodes reject some blocks older nodes may still accept.
- miner signaling → Miner signaling is when miners mark blocks to show support for a proposed rule change.
- OP_RETURN → OP_RETURN is a way to put a small piece of data into a Bitcoin transaction without creating spendable coins.
BIP-110 is running out of miners. The proposal would temporarily restrict several ways people store non-payment data on Bitcoin. As of July 18, public monitoring showed signaling below 1% in the current period.
That is the only number that matters. BIP-110 needs 1,109 signaling blocks in one 2,016-block period for early lock-in. The current period had only a tiny fraction of that support.
The code-level rule is blunt. New output scriptPubKeys over 34 bytes become invalid, unless they are OP_RETURN outputs up to 83 bytes. OP_PUSHDATA payloads and many witness items over 256 bytes also fail. The proposal also blocks undefined witness versions, Taproot annexes, oversized Taproot control blocks, OP_SUCCESS opcodes, and Tapscript OP_IF or OP_NOTIF execution.
At the contract level, this is not just an inscription filter. It changes what some future Taproot-style scripts can safely assume for a year. The BIP itself says the tradeoff includes possible pressure on BitVM-style designs and some Miniscript patterns.
If you're running infrastructure around Bitcoin transactions, this is a compatibility problem before it's a culture fight. A node enforcing BIP-110 can reject blocks that everyone else still builds on. That does not make the majority wrong. It makes two views of valid Bitcoin blocks exist at once.
Adam Back's public pushback matters because Bitcoin politics still run on rough consensus. Back is Blockstream's CEO, the Hashcash inventor, and one of the first two people Satoshi Nakamoto emailed. U.Today reported that he dismissed the Satoshi-based case for BIP-110 and treated his Satoshi comments as speculation, not evidence.
Read the deployment mechanics, not the thread. The proposal's mandatory-signaling path points toward block 961,632 in early August. Maximum activation sits around block 965,664. That path can force the question, but it cannot manufacture broad consent.
The tradeoff is spam resistance for consensus risk. Policy filters can be annoying and incomplete. Consensus changes are harder to unwind once users split over them. For now, BIP-110 looks less like an incoming Bitcoin upgrade and more like a formal deadline for a coalition that never arrived.
BIP-110's authors choosing mandatory signaling with sub-1% miner support was reckless because it turns a spam dispute into chain-split machinery.
Before block 961,632 in early August, watch whether BIP-110 signaling reaches 1,109 blocks in any 2,016-block period; below that, the deadline stays a minority-enforcement fight.
Primary links and supporting reads used by the desk for this story.
Forward this.
