I tested it against scripture and it fails the test. Scripture doesn't back it and even done what would make it to where it could pass. WHAT FAILS AND WHAT WOULD HELP IT PASS What Fails 1. It Violates Protocol Neutrality BIP-110 tries to enforce a subjective value judgment about what Bitcoin should be used for. It renders currently valid, fee-paying transactions invalid at the consensus layer. "Dislike does not equal invalidity," as Michael Saylor stated. If a transaction follows the rules and pays fees, it is legitimate, even if someone doesn't approve of its content. 2. It Centralizes Power By moving anti-spam policies from the forwarding/ mining strategy layer to the consensus layer, BIP-110 changes the nature of the issue. It creates a precedent where consensus rules can be changed based on a subjective "spam" label. Adam Back argues this conflicts with Bitcoin's permissionless design: no one can impose their value judgments on others. 3. It Bundles Unrelated Restrictions The proposal lumps together seven separate consensus changes. This means participants cannot support one restriction while rejecting another. This bundling risks stifling legitimate use cases and future upgrade paths. 4. It Closes Off Future Upgrade Paths BIP-110 disables multiple future upgrade paths, including OP_SUCCESSx, the Taproot annex, and future witness versions. This "shuts down multiple upgrade paths at once," which should not be done without a very compelling reason. 5. It May Not Even Solve the Problem Even if activated, BIP-110 may not actually block arbitrary data. A developer demonstrated writing a 66KB TIFF image in a single transaction without using the targeted features. Tools like DOG Mode are also being developed to relax BIP-110's restrictions. 6. Miner Support Is Virtually Nonexistent The proposal relies on a User-Activated Soft Fork (UASF) rather than broad miner consensus. Miner signaling has never exceeded about 1%, far below the 55% threshold. No major mining pool supports it. 7. It Has a Consensus Bug The activation client contains a vulnerability on late upgrade paths. A node that upgrades later may retain block data accepted under old rules that would be rejected under BIP-110, creating a split. What Would Help It Pass 1. Respect Protocol Neutrality A revised proposal must stop trying to enforce a subjective vision of "monetary purity." Transactions that follow the rules and pay fees should remain valid. A neutral protocol treats all fee-paying transactions equally, regardless of their content. 2. Unbundle the Changes Each restriction should be introduced with its own precise reasoning and justification. A broad, bundled restriction risks stifling legitimate and future use cases without proper debate on each individual rule. 3. Preserve Future Upgrade Paths The proposal must not disable future, carefully considered upgrade paths reserved for future soft forks. It should better preserve compatibility with projects like BitVM and Miniscript. 4. Prove an Objective Need The proposal would need to define the objective "node burden" it aims to reduce and quantify the actual threat to decentralization. It must demonstrate how it would lower transaction fees and for whom. Currently, it lacks this data. 5. Gain Miner Consensus A proposal with virtually no miner support and relying on a UASF lacks legitimacy. Any workable proposal would need broad acceptance across miners, node operators, and the ecosystem. 6. Respect Technical Consensus Process Adam Back describes Bitcoin's technical consensus process as a form of "protective resistance." Any protocol change must undergo scrutiny from a large number of developers and protocol observers. This process is slow by design to prevent unproven changes from eroding foundational attributes. The Principle to Uphold Consensus rule changes should be rare, boring, and almost without controversy. They should not be used to solve cultural differences in a permissionless system. The proposal must serve the principle of neutrality by not punishing valid, fee-paying transactions. These are not just technical adjustments. They represent a shift in the social contract of Bitcoin. Any proposal that restricts economic freedom on the basis of subjective value judgments should be taken as a warning sign.