That’s exactly the point of running your own node, you decide your relay and validation policies, and I decide mine. If my node doesn’t relay your BIP47 or tx0 transactions, it’s because I’ve chosen tighter policies to reduce unnecessary data and long-term storage risk. You can route around it, that’s how Bitcoin’s peer network is designed to work.

Knots isn’t “propaganda.” It’s Bitcoin Core with additional configurability and better defaults for people who take node sovereignty seriously. Both Core and Knots enforce the same consensus rules, neither breaks Bitcoin, and both coexist perfectly fine on the network.

If you prefer to relay every kind of transaction, go ahead. Others choose to run leaner, more conservative nodes to avoid bloat and potential legal or operational risks. That’s not brainwashing, that’s responsible node operation and informed choice.

You’re correct that Core v30 didn’t change the OP_RETURN limit itself, only the default relay policy. However, as a node operator, I’m free to enforce stricter policies locally, and I intend to.

I don’t want to relay or store larger OP_RETURN transactions because:

1. Legal risk: Hosting or relaying arbitrary on-chain data (especially CASM content) is illegal under EU law when it includes copyrighted or illicit material. As a node operator in the EU, I have a legal obligation to minimize exposure to such data.

2. Network efficiency: Larger OP_RETURN payloads bloat the UTXO set and mempool bandwidth without contributing to Bitcoin’s core purpose, financial settlement.

3. Principle of minimalism: Bitcoin’s design goal is censorship resistance for money, not a general-purpose data storage system. Keeping relay policies tight preserves the network’s scalability and neutrality.

So while Bitcoin Core’s position is about maintaining realistic relay behavior, my stance as an operator is simple: my node, my policy. I will not relay or store CASM or any non-financial payloads. Don’t care if it’s Core or Ocean propaganda, try to apply common sense.