What's incredible is that I heard this verse spoken about on a podcast with Robert Breedlove and Jeff Booth. Then again from my wife. Then again from her mother. I am no longer surprised but I am always amazed.

I would wager, to make a point to certain people.

Yoooo, very cool! Downloading frens to trade moneyz with 🥲

I don't care what spammers do to get their data on chain. What I do care about ia having the option to do what I want with my computer. That's it. Everyone keeps turning the discussion to "If you were king of Bitcoin how would you stop spam?"

I am just one participant, with a few nodes, that wants to run code with more options not fewer, okay?

Sure, I am not against OP_RETURN having no technical limit. What I am against is making the field unpruneable. If I want a limit on MY mempool's acceptance I don't want to have to fork the software. That's ridiculous. Also, keep the default where it is and let the spammers increase their OP_RETURN data carrier limit. That is more than fair. Spammers set their data carrier limits and do their worst. Others who disagree can run their filters and see who is more prevalent on the network.

I don't just relay to Ocean.I have peers and I have a morality to not pass along spam. I don't go around forwarding spam emails either.

Becuase I do want to relay transactions within MY personal params. This feels like a disingenuous question.

Me: I don't want to eat junk food

You: why eat food at all?

Me: because I DO want to eat, just not that.

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.

The mempool resource, obviously. Being forced to hold spam on my mempool is a resource I do not want allocated to my storage or memory.

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.

Accurate

Man, if social media campains to influence people are the problem, I heard about this neat protocol...do you like purple?

It's so funny I feel like we are saying the same thing at different times.

My point is that if I run code that I agree with my mempool doesn't propagate things I consider to be spam. I have no illusions that if a miner mines a valid block with transactions I dislike, I will still have to store that block in my UTXO set. But the choice of not propagating trash is what is up for debate here not the bounds of a valid transaction in the block.

Yes, then I am at that maintainer's mercy as well. I respect your adversarial thinking and contributionsin terms of security. I just think for some reason, in this context there is a misalignment of incentive and I am not quite sure why you don't see it.

Not if I don't write code and fork Core soon enough. Removing choice being framed as freedom of choice, seems odd.

Disagree.

That is already the case with node mempools, no? My mempool doesn't accept over 80 bytes in OP_RETURN data. Other peers do. My node finds those transactions invalid.

The implementation that has a bug is the same as a Core node that accepts 400k bytes of data in a trasaction to my node.

To be clear there is no canonical implementation of bitcoin. The software does a few things invariably and the rest is preference. Validations, unconfirmed transaction pool, peer connection, and transaction broadcasting.

Your money wouldn't break though? Your UTXO is still valid, your transactions would still be broadcasted, and you would have values that tell peers what you find valid.

Think this way: if you only used dollar bills that have certain serial numbers all you are doing is making it more difficult for yourself to acquire valid dollars (in your opinion). But most people use default configs so there's your general consensus. Unless one of the defaults is obnoxious or dumb most will toggle off as a step of setup.

Yeah, I am honestly surprised there aren't more implementations of Bitcoin in every language with a million config toggles. If only Libbitcoin worked...

Yes.

It also costs more to write graffiti on a mansion with high security than a townhouse in a city with no security.

You can create cost multiples by adding more security. When this is code, the cost to attack versus cost to cost to defend shifts dramatically.

Cost comes in many forms.

I mean people may extrapolate and conflate their own node policy with the network at large.(My node filters spam so, "if everyone else does what I do" then spam will be "gone") But at some point that does become the reality if people prefer that policy just from a feasibility aspect. Spam would HAVE to be side loaded to a miner making it cost prohibitive.

Everyone does only one side (the spammers) complain about censorship and are therefore hypocrites.

Not the point. Disallowing things outright stops it...on your computer. THAT is the point. No one is under the illusion that this OP_RETURN limit prevents spam outright. It is a choice that should be left to the end user. If 99% of users disable the limit, arbitrary data is valid by consensus. If 99% keep the limitation, then arbitrary data is limited by consensus.

Taking away the choice is the contention not the spam itself.

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.

I followed the wizard an it has a few issues imo.

It derives the keys for you.

It mandates an email.

It only suggests 5 clients at the end none of which are the most popular.

I truly think starting with a key manager (amber or Nos2X) would keep the key creation more secure and as the find more clients beyond Satoshi Settlers, they will be able to take their secure keys with them.

Totally agree but that's the DNS infrastructure and ISPs fault not the tech. There's a much easier way to ensure that IP address are addressable and don't have collisions without a central authority. But, I'm not the Satoshi of the internet, I care too much about not hiding or being dead.