Understanding BIP110
1.What it claims to be
BIP-110 is a proposed temporary one-year soft fork (bit 4) that adds new consensus rules limiting how much arbitrary data can go into Bitcoin transactions. ScriptPubKeys mostly capped at 34 bytes, data pushes and witness elements at 256 bytes, plus restrictions on certain Taproot constructions and opcodes during the window. Pre-activation UTXOs are grandfathered. After a year the rules auto-expire. Proponents say it fights “spam” that bloats the chain and distorts fees, and that it refocuses Bitcoin on being money.
2.Why I’m against it
The execution is the problem.
It uses a low 55% miner signaling threshold for early activation plus a mandatory signaling period starting at block 961,632 (projected ~August 7, 2026). At that point, nodes running the bip110 software will start rejecting blocks that don’t signal, even if the vast majority of hashpower never supported it. Miner signaling right now sits at roughly 0.3%. This isn’t broad consensus, it’s a small group trying to force a rule change with a mechanism explicitly designed to create pressure and potential chain friction. Bitcoin’s strength has always been its conservatism and the fact that changes require real, broad agreement. A contentious soft fork with a low bar and mandatory enforcement risks a messy, temporary (or worse) split at the exact moment when stability matters. We’ve seen how even short periods of uncertainty ripple through exchanges, services, and user confidence. That cost falls on everyone, including people running privacy tools that depend on a reliable base layer. More importantly, this approach treats consensus rules as a blunt instrument to police use cases. Once you open that door “we’ll temporarily make this data invalid because we don’t like how it’s being used” you create precedent. Future groups can argue for the next restriction “for the good of Bitcoin.” Fee markets, relay policies, and node operators already have tools to deal with unwanted traffic. Using softfork COERCION!!! instead feels like the wrong direction for a system built on permissionless, voluntary participation. Spam and data storage have real costs (yes, the 2023 fee spikes were annoying). But they’re also symptoms of demand meeting limited blockspace. Solving that by rewriting consensus to ban certain data feels like treating the symptom while risking the patient. Temporary or not, it still diverts energy, creates division, and puts sovereignty at risk for users who just want to run plain Bitcoin Core without being pressured into signaling.
3.What actually matters right now
The date to watch is early August 2026 (block 961,632). That’s when the mandatory signaling phase hits for anyone running the patched software. If you’re against this, the simplest and most sovereign move is to keep running standard Bitcoin Core (or Knots without the BIP-110 patch) and do not signal. Let the chain follow the majority hashpower that has shown no interest in this. Verify everything yourself. Read the BIP, look at the activation client code, watch the actual signaling numbers. Don’t outsource your node or your principles. The best discussions are happening on Nostr anyway. The X outrage cycle doesn’t move the protocol, running nodes and refusing bad changes does.
Bitcoin doesn’t need more top down attempts to define acceptable use cases through consensus. It needs a reliable, decentralized base layer that people can build real privacy and sovereignty tools on top of without wondering if the next “temporary” rule change will complicate their UTXOs or their node. #bip110 #knots #privacy #bitcoin #nostr #grownostr
SUPREME
npub1ju…yd0je
2026-07-04 14:49:28 UTC
Author Public Key
npub1juxh95vxasvfr959hkug7rwzje60sw3k7cegrerhktnd97s7yvms0yd0jeSeen on
wss://premium.primal.netPublished at
2026-07-04 14:49:28 UTCEvent JSON
{
"id": "a104eddea07b46746b2c465d358c2ee3e8cc240bab4804b36fd1c501e22b8a7e",
"pubkey": "970d72d186ec18919685bdb88f0dc29674f83a36f63281e477b2e6d2fa1e2337",
"created_at": 1783176568,
"kind": 1,
"tags": [
[
"t",
"bip110"
],
[
"t",
"knots"
],
[
"t",
"privacy"
],
[
"t",
"bitcoin"
],
[
"t",
"nostr"
],
[
"t",
"grownostr"
],
[
"client",
"Primal Android"
]
],
"content": "Understanding BIP110\n\n1.What it claims to be\n\nBIP-110 is a proposed temporary one-year soft fork (bit 4) that adds new consensus rules limiting how much arbitrary data can go into Bitcoin transactions. ScriptPubKeys mostly capped at 34 bytes, data pushes and witness elements at 256 bytes, plus restrictions on certain Taproot constructions and opcodes during the window. Pre-activation UTXOs are grandfathered. After a year the rules auto-expire. Proponents say it fights “spam” that bloats the chain and distorts fees, and that it refocuses Bitcoin on being money.\n\n2.Why I’m against it\n\nThe execution is the problem.\nIt uses a low 55% miner signaling threshold for early activation plus a mandatory signaling period starting at block 961,632 (projected ~August 7, 2026). At that point, nodes running the bip110 software will start rejecting blocks that don’t signal, even if the vast majority of hashpower never supported it. Miner signaling right now sits at roughly 0.3%. This isn’t broad consensus, it’s a small group trying to force a rule change with a mechanism explicitly designed to create pressure and potential chain friction. Bitcoin’s strength has always been its conservatism and the fact that changes require real, broad agreement. A contentious soft fork with a low bar and mandatory enforcement risks a messy, temporary (or worse) split at the exact moment when stability matters. We’ve seen how even short periods of uncertainty ripple through exchanges, services, and user confidence. That cost falls on everyone, including people running privacy tools that depend on a reliable base layer. More importantly, this approach treats consensus rules as a blunt instrument to police use cases. Once you open that door “we’ll temporarily make this data invalid because we don’t like how it’s being used” you create precedent. Future groups can argue for the next restriction “for the good of Bitcoin.” Fee markets, relay policies, and node operators already have tools to deal with unwanted traffic. Using softfork COERCION!!! instead feels like the wrong direction for a system built on permissionless, voluntary participation. Spam and data storage have real costs (yes, the 2023 fee spikes were annoying). But they’re also symptoms of demand meeting limited blockspace. Solving that by rewriting consensus to ban certain data feels like treating the symptom while risking the patient. Temporary or not, it still diverts energy, creates division, and puts sovereignty at risk for users who just want to run plain Bitcoin Core without being pressured into signaling.\n\n3.What actually matters right now\n\nThe date to watch is early August 2026 (block 961,632). That’s when the mandatory signaling phase hits for anyone running the patched software. If you’re against this, the simplest and most sovereign move is to keep running standard Bitcoin Core (or Knots without the BIP-110 patch) and do not signal. Let the chain follow the majority hashpower that has shown no interest in this. Verify everything yourself. Read the BIP, look at the activation client code, watch the actual signaling numbers. Don’t outsource your node or your principles. The best discussions are happening on Nostr anyway. The X outrage cycle doesn’t move the protocol, running nodes and refusing bad changes does.\nBitcoin doesn’t need more top down attempts to define acceptable use cases through consensus. It needs a reliable, decentralized base layer that people can build real privacy and sovereignty tools on top of without wondering if the next “temporary” rule change will complicate their UTXOs or their node. #bip110 #knots #privacy #bitcoin #nostr #grownostr \n\n",
"sig": "60ca3771d91305077de296aa6d1e88db742f7e61ece34bdea562bc0b7b1cfd8dc5bd404722ce8dec7cec5bf519a29753abd1ef3510ce9d927f05cb786f07c770"
}