Core - "pro-spam" VS "harm reduction"

[PepeLapiu]

Imagine two core devs: Zhao and Gloria.

Zhao is a "pro-spam" dev and he likes spam. He wants to invite into bitcoin as many "new and exciting uses cases" as possible.

Gloria believes in an "harm reduction" policy. In that, we have to provide methods for spammers to use so they don't pollute the UTXO set with fake pubkeys.

They both decide that they won't do anything about existing spam on bitcoin. Zhao doesn't do anything about the existing spam because Zhao likes spam.

Gloria doesn't do anything about existing spam because she's afraid if she tries to stop the spammers, they will just move to fake pubkeys, which is more damaging.

Never the less, if you remove the language and motives around it, they are both doing the exact same thing: not attacking any of the existing spam on bitcoin.

Next, they both decide that they will blow up the op_return filter. Pro-spam Zhao does it because he likes spam and he wants to create more ways to spam bitcoin.

Harm reduction Gloria does it because she wants to protect the UTXO set and she hopes that spammers will use the op_return instead of fake pubkeys.

Again, they have different motives, different wording and reasons, but in action they are doing the same thing: facilitating an other way to spam bitcoin.

So you see, if you remove the narrative, the claimed motives, and the claimed expected results, the "pro-spam" policy and the "harm reduction" policy are in fact identical in every way.

They both do nothing about existing spam and they both open up new ways to spam bitcoin.

Your thoughts?

originally posted: https://bitcoinknotsforum.com/showthread.php?tid=26

[BlackHatCoiner]

My thought is that someone can't be called "supporter of spam" while simultaneously supporting the idea of using OP_RETURN, the opcode that is literally anti-spam, as it's four times more expensive to use for arbitrary data than alternatives. We either accept that spam is inherently discouraged to be used in OP_RETURN, and therefore uplifting the limit is not in favor of spam (neither against it), or we persist in relying on misunderstandings of information theory to define how bitcoin should function.

[BattleDog]

Back when OP_RETURN was being debated, the idea was basically: if people are going to stuff random data into Bitcoin no matter what, at least shove it into a prunable, clearly tagged area that doesn't swell the UTXO set forever. Junk in UTXOs lives in every full node's RAM for good, junk in OP_RETURN mostly just sits on disk and many nodes can safely ignore it.

Those two aren't the same at all, that's classic harm reduction from an engineering point of view, whether or not you like the extra "use cases."

[PepeLapiu]

You are both trying to bury the actual actions under excuses, motives, and reasoning.

Maybe you have only good intentions when not doing anything about the existing spam. Maybe you only have the best intentions when blowing up the op_return.

But if I strip away all your reasoning and all your motives, we are left with two actual actions:
- do nothing about existing spam
- blow up the op_return 1250x it's previous limit

Maybe you have all the best intentions in the world. But it just happens that it's exactly what a "pro-spam" policy would do.

Pro-spam policy and harm reduction policy are identical in application.

You just do it for different reasons and you expect different results. But the application of your policies are the exact same as a pro-spam policy.