Bit-Block.org

This blog post is a direct (and edited) copy of the topic I made on X (formerly twitter).

The breakdown

What does this proposal do? — — — —

As the title of the BIP444 (now BIP 110) mentions = Reduced Data Temporary Softfork.

It is a temporary softfork aiming to limit the size of data fields at the consensus level.

Basically a counter on what Bitcoin Core V30 introduced when they removed the limits on the OP_RETURN function. The difference here is that BIP444 will be re-introducing the limits (temporarily) for OP_RETURN as well as limit the possibility to store data in other functions. Those other functions being mainly related to exploits that Ordinals have been abusing since early 2023. The introduced limits will effectively halt the creation of Ordinals.

What limits does BIP444 (now BIP 110) introduce? — — — —

Taken directly from the proposal:
– New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
– OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
– Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)
– Witness stacks with a Taproot annex are invalid.
– Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
– Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
– Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

–> When reading through the proposed limits, we immediately notice that the limits are directly imposed on functions barely used and whose current established limits were either too high or unused. Noticeable is that the imposed limits on actively used functions are in line with genuine monetary use and the prevention of pushing data. We even see a push for OP_RETURN use (which Core V30 proponents pushed to mitigate abuse) while setting the limit again to 83Bytes (Core V30 uncapped the limit and made it possible to save data up to one MB in size in said function).

The latest version of BIP 444 can be found here.

Important notices and remarks:

• Proposal is not active yet. Activation may occur starting from block 987424. As of writing, we’re currently at mining block 920998. POSSIBLE activation is thus projected for early 2026. Meaning the BIP can be changed still based on feedback.
  
  Edited June 2026:
  A few changes in regards to activation have occurred in the last couple of months.
  Presets are now the following:
  – Signalling started in December 1st 2025
  – If 55% of miners signal support in a 2016-block window, BIP-110 will activate 2 weeks later
  – Somewhere in September 2026 at block 965664 will BIP110 activate unconditionally

• A recurring argument against BIP 444 (now BIP 110) would be that of “censorship”. Censorship has ALWAYS been part of Bitcoin in regards to transaction validation. This comes with Bitcoin being designed as a currency and not a free for all data cloud storage service. While spam did exist in the past has the severity increased in the last 2 years which now forces a step in to halt it entirely for the sake of giving Bitcoin a future as hardest currency ever. This proposal introduced data pushing limits to prevent more spam from happening while favoring real monetary transactions.

• “Legal talk” and supposed “cucking to Government” in the proposal break down. –> is an actual appeal to your morality. There are things happening in this world which should not be. The majority of people talk about legality while in reality it is all about morality. It is not “punk” to allow immoral things to take place under the guise of “muh freedom”. More than often are you virtue signalling (for) degeneracy (to take place).

• @nitesh_btc made a small list of points. (see image below)
  Rebuttals and remarks:
  
  — They want to remove OP_IF for tapscript because they think we can figure shit out offchain.
  -> The function OP_IF is redundant. The real question is, figure out “what” offchain? The answer will mostly be about smart contract capabilities and the means to shitcoin on Bitcoin (and other things not related to “Bitcoin as a currency”).
  
  — They want things like BitVM and other stuff to go silent until they give us further instructions on when they can resume work.
  -> BitVM is mostly for L2 development. The majority of use BitVM is seeing is for Smart Contract applications and creating….. “drumroll”…. shitcoins on Bitcoin. BitVM is the literal counterpart of EVM (Ethereum Virtual Machine) for Bitcoin. In a very condensed, plain-English, explanation: BitVM doesn’t support the idea of “Bitcoin as a currency” and is more about “Bitcoin as a DApp chain”.
  
  — Apparently we’ll all be in trouble if we reject their soft fork.
  –> I have to admit, I don’t like the used wording either yet I subscribe to the idea of urgency to take drastic steps to mitigate and halt spam.
  
  — And bottomline after all this, it doesn’t solve spam.
  -> This is an outright lie in the sense of obfuscating the truth and not mentioning nuance. Imposing the limits will halt +90% of current spamming. It’s not the full 100%… but those odds are high enough.

• @mononautical made the argument of possible confiscating coins (see image below). It’s a good argument. Myself I’d say we need to look a bit deeper into that and probably adjust that limit to avoid the scenario. .. if we don’t want “confiscated Bitcoin”, it stands to reason we reject Jameson Lopp’s BIP for quantum resistance as it is entirely based on hijacking coins in old wallets (See proposal here: https://github.com/jlopp/bips/blob/quantum_migration/bip-post-quantum-migration.mediawiki ).

Edited June 2026:
–> The confiscation risk mentioned is rather deep and EXTREMELY exclusive in nature (an extreme edge-case used by none and purely theoretical).
With this, it is meant that a set of conditions must be met before confiscation can occur. To this I refer to PrivKey’s blog who does a complete and simplified breakdown. Direct quote:

Critics claim BIP 110 could freeze or confiscate people’s bitcoin. Let’s look at what would actually have to be true for that to happen. All five of these conditions would need to be met simultaneously:

• The coins are in a Taproot (P2TR) output

• The coins are locked in a pre-signed transaction

• The coins must be both confirmed and spent during the one-year deployment window

• The specific Tapleaf being used to spend them violates one of BIP 110’s rules (contains OP_IF or sits deeper than 7 levels in the Taptree)

• There is no other way to spend the coins: no keypath, no other valid Tapleaf in the tree

If even one of those conditions isn’t met, the funds are completely fine.

How likely is this scenario? Extraordinarily unlikely. The vast majority of Bitcoin users don’t use Taproot at all yet. Of those who do, almost none use deep Taptrees or exotic Tapleaf constructions. Of those who do, almost all have a keypath spend available as a backup.

But BIP 110 goes even further to protect users:

UTXOs created before activation are completely exempt. The new rules only apply to outputs created after the fork activates. Your existing coins are untouched.

There’s a two-week grace period between lock-in and activation, giving anyone with edge-case setups time to move their funds.

Could someone, somewhere, theoretically be affected? In the most extreme edge case, maybe. But we’re talking about a scenario so unlikely it’s like worrying about a meteor hitting your house while your house is on fire. The fire, inscription spam consuming 37% of block space and pricing regular users out of the network, is the actual emergency.

• @zndtoshi (and others) frequently compare it to SegWit and Taproot. Even going as far to claim that BIP110 would change Bitcoin in that it would become an entirely different version (i.e. not Bitcoin as we know it). This is, ofcourse an outright lie as BIP110 TIGHTENS existing rules and does not add additional functionalities like SegWit and Taproot did. It restricts existing programmable functions, meaning activation makes Bitcoin closer to money (and OG intent). It reaches back to a Bitcoin to a state of pre-Segwit and pre-Taproot (in a sense).