Again, I don't like inscriptions, never held any, think they're stupid. I work on Bitcoin the money.

I don't think your preferred remedy helps in any interesting way and it's itself potentially harmful

I don't see how RAM or CPU are negatively affected. I don't see how it costs more energy either. Inscriptions have fewer signature operations per data than other transactions. And nodes that filter their mempool still get the whole block, only marginally reducing bandwidth use.
So, I don't see why filtering is helpful for any of those four concerns.

Murch

No one's making you do anything. You are though, volunteering your time to voice your opposition to what you view as virtue signalling. While parroting the same tired false goal post I make a point of calling out in my article. baffling.

I view this anti-spam activity as reducing moral hazard and overall risk, while preparing for the worst case scenario.

RAM, CPU, Bandwidth and energy costs are all of concern here.

If normal people can't run a node because of this activity in 14 years, we have a problem.


BITC0IN

bitcoin

Bitcoin Filters Work By Default, and That's a Good Thing!

I don't think it makes a significant difference to forward the transactions with the blocks or when they're relaying unconfirmed. The node might save a few inv messages and forwarding a tx once or twice. If that bandwidth savings is of concern, `blocksonly` would be more effective at reducing bandwidth use.

I don't see any non-marginal benefits to be achieved by filtering unconfirmed inscription txs beyond virtue signaling, and I don't think working on enabling virtue signaling is a good use of my time.