Thanks for the thoughtful reply. Just to clarify - there wasn’t a controversial update pushed by Core developers. From what I understand, there was a proposal to raise the default OP_RETURN relay limit. It triggered discussion, but nothing was merged. The PR was closed. No rules were changed. No behavior was imposed on node runners. That said, I have a genuine question, and I’m not asking this to argue - I really want to understand better. Do I understand correctly that what your node is doing is mostly symbolic? From my current understanding: Your node still downloads and processes those valid transactions before dropping them. Then, when those same transactions appear in a block, your node processes them again to validate the block. So essentially, it’s doing twice the work. The data still hits the blockchain, because it’s valid and paid for through fees. And the mempool is still exposed to the same total load, just shuffled differently. Also - by rejecting valid transactions at relay level, nodes like Knots don’t just increase their own processing burden. They may also add inefficiencies to the broader network by breaking natural transaction propagation paths. It’s a kind of bottlenecking, but without stopping the end result. If I’m missing something here, I’m open to being corrected. I just want to get to the root of how this improves the system beyond making a statement.

Replies (1)

The Bitcoin Core team announced that they were removing the op_return limit in the next iteration of Core. If that has changed, I am unaware. Yes, I understand my actions are symbolic. I only have 1.5 TH pointed at my node. Yes, I understand this is more computational work for my node. Doing the right thing is usually not the easiest thing. We disagree on what a “valid transaction” is. I believe it is data that includes information pertaining to monetary transactions only. You believe pictures are a “valid transaction”. Peter Todd is at the forefront of this op_return limit removal. He also supports genocide. So…