As expected, it has very soft language surrounding the financial implications. Arguing "filtering non-standard transactions could be harmful because the nodes are missing out on part of the network"

What part exactly? Spam. Obviously this is up to the code runner to determine. Previously this had been 83 bytes of data. With an unconfigurable, limitless OP_RETURN it is billed as:

Well the attackers are running software that can increase the OP_RETURN anyway so why would we allow you to run software that disallows it on YOUR node?

Utter nonsense.

The next town allows people to spraypaint anyone's house with their messages. So, it's useless to prevent it in our town because they will just go over there and do it.

The point is lost on him that there's a reason different towns have different rules. Each one having their own...wait for it, CONSENSUS!

This blog post is invalid in my mental data set, it doesn't mean it doesn't or won't exist but, I am not storing it in my brain.

Reply to this note

Please Login to reply.

Discussion

Every node has to have the same consensus rules, we are debating policy here, which only effects the mempool and may indeed be different. If the data carrying transaction propagates no matter if it is switched on or not, and the transaction does not incur disproportionate cost to validate and relay, there is little point in not relaying it, since it is latest reveived and processed by the node by the time it is mined.

And as I have stated on many other threads on this topic, a consensus has a definition that I am using. If I meant , , or I would have said that.

As for the cost, yes it does. If the only way to propagate spam was to have a sidechannel to a miner that is socially coslty, technically costly, and still block weight costly.

If every peer you connect to rejects your transactions as invalid by not keeping it in their mempool, that make it a time and opportunity cost as well.

This always smack of the little girl throwing fish back into the ocean that washed ashore. She'll never be able to save them all but that's not the point. The ones she did save are grateful. Never tell anyone that doing what they believe has "little point" because it alone doesn't fix the problem. It is the agregate actions of many that do.

Paying to a fake key or hash cannot be controlled by policy, no matter how aggressive you get. You might say this is expensive, but not by much more than embedding data in fake p2ms (which is controllable by policy). Is there a point to forcing people into the worst class of data embedding in terms of node resource consumption?

Because Bitcoin is not a distributed data storage service. It is a monetary network for monetary transactions. Paying a fake key IS a financial transaction at the end of the day. If I pay a shell company for items that I never receive I still paid it.

Preventing spam is not the point anyway, it is this strange reframing of "We are taking away a config option which gives you more freedom"

This is blatantly false and could only serve to make spam easier to do. That is the contention, nothing else.

I don't care if spam actually increases or decreases. I want people to FREELY choose to enable spam or disable it. Everything else is sophistry.