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.

• 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 ).