Thanks for the feedback.

It doesn't help.

I think it helps a lot to explicitly declare by consensus that arbitrary data storage is not a supported use case. Almost every Bitcoiner I've ever met wants Bitcoin to be money, and thinks it should not be data storage.

I don't think Bitcoin can survive as money if it is also trying to be data storage in addition to being money. I think the spam attacks we endured recently would not have happened if Bitcoiners had committed to rejecting the data storage case prior to 2023. Part of the spammers' narrative was "we're helping Bitcoin by contributing fees to miners". BIP-110 sends a clear signal that filling blocks with data spam that makes Bitcoin less useful as money, far from "helping", is an abuse. So in the future, if shitcoiners attempt similar attacks again, such activity will be immediately recognized as abuse and promptly filtered.

The witness inscription protocol for spreading over multiple utxo already exists because shitcoiner orditards needed it.

Yes, this is why BIP-110 explicitly invalidates inscriptions. Core 30 sends a message that inscriptions are an officially sanctioned use of Bitcoin, because part of the rationale for removing the OP_RETURN limit was "people are already using inscriptions anyway". BIP-110 restores the situation to how it should be (and how it was from 2010-2022), which is that Bitcoiners actively resist data spam without ceding an inch. This is necessary in order for Bitcoin to succeed in its mission of becoming the new global reserve asset.

It's too restrictive and you know this because you made exceptions to the rules for existing solutions that can't be fit inside your proposed new rules, for example: OP_RETURN scriptPubKey size exclusion
OP_PUSHDATA* exception for BIP16

The reason for the OP_RETURN and BIP16 exceptions are explained in the BIP:

OP_RETURN:

What about OP_RETURN? Why not get rid of it entirely?
OP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set. Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and no legitimate uses have ever been found. With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated. However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.

BIP16:

Why is there an exception for BIP16 redeemScripts?
The content of redeemScripts are another script, which is then executed. Its contents are then also subject to the same OP_PUSHDATA* restrictions. Restricting it is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.

You can read the entire rationale here: https://github.com/dathonohm/bips/blob/reduced-data/bip-0110.mediawiki#specification-nuance. Let me know if anything is not clear and I can update the BIP document.

What if a change is needed on short notice that needs more than 34 bytes?

What change would that be? Taproot allows for very complex spending conditions, even limited to 7 levels deep as in BIP-110.

This is also explained in the BIP:

Why limit scriptPubKeys to 34 bytes?
scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes. They generally cannot be pruned. They are also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice; actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. Furthermore, large scriptPubKeys, in addition to being a data embedding vector, can be abused to create malicious transactions and blocks ("poison blocks") that take a long time to validate. Large scriptPubKeys, thus carrying a large abuse potential and no benefit, are invalidated by this BIP.

Again, let me know if you think this section could be clarified.

Banning unused witness program numbers other than 0 and 1 and OP_SUCCESS* explicitly removes future extension, which is a major setback for anyone working on protocol updates. You would explicitly block GSR, lnhance.

This is also addressed in the BIP:

Why make spending undefined witness/Tapleaf versions invalid?
Since they are undefined, witness stacks spending these versions are completely unlimited currently to allow maximum flexibility in future upgrades. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.

It is very doubtful that GSR or LNHANCE would have consensus by the time BIP-110 expires (September 2027 or earlier), but if it does, then there is no problem - we can just activate the new features then. (It is worth noting that CTV, a component of LNHANCE, would be compatible with BIP-110 since it uses OP_NOP rather than OP_SUCCESS. But again, if there is consensus for a proposal that needs upgrade hooks, waiting a year to deploy it would not be out of the ordinary.)

(1/2, continued in reply)