I am already on the right side of history , would like to see the full documents on it to test it against scripture see if it stands in truth.

Documents on what? There's plenty on online documents on 110. And rebuttles.

This is what desparation looks like

Who knows

Yep I tested it , it shows thAt it fails.

I follow Matthew Kratter and enjoy his channel but honestly this is a really bad look. Makes one reconsider all his pro BIP110 arguments.

You tested what? 110? Please elaborate. Sounds fascinating...

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.

Are you a bot? Brandolinis Law in action over here.

No I am human I got a YouTube channel and Podcast. I use what I have found in the biblical text and run it through AI I need to make my own app that does this for the people.

You asked: "Are you a bot?" No. I'm just someone who tests things. You invoked Brandolini's Law — the idea that bullshit takes less effort to create than it does to debunk. And you're right. But that doesn't make the debunking less true. I tested BIP-110 against scripture. It fails. Not because I want it to fail. Because it doesn't hold up. What Fails: 1. It violates protocol neutrality. Dislike does not equal invalidity. 2. It centralizes power. It moves anti-spam to the consensus layer, which is a precedent. 3. It bundles unrelated changes. You can't support one and reject another. 4. It closes off future upgrade paths. 5. It may not even solve the problem. 6. Miner support is virtually nonexistent. 7. It has a consensus bug. What Would Help It Pass: 1. Respect protocol neutrality. 2. Unbundle the changes. 3. Preserve future upgrade paths. 4. Prove an objective need. 5. Gain miner consensus. 6. Respect the technical consensus process. This isn't about being against Bitcoin. It's about being for truth. And truth can stand up to testing.