npub10l…ms9ug on Nostr: We periodically patch our operating systems to mitigate known security ...

We periodically patch our operating systems to mitigate known security vulnerabilities. Misuse of the protocol for non-financial use cases is similar to security vulnerabilities, and warrants periodic patches to mitigate it.

Spam damages the financial use cases in the long term by increasing node costs and discouraging plebs from running nodes because they don’t want to deal with the increased legal risks from spam content. Both of these incentives centralize nodes over time, and for what purpose - to enable spam?

The patches should be as minimal as possible and ideally restricting existing functionality rather than adding new functionality to reduce the risks of introducing unintended consequences.

I don’t agree with Luke’s puritan views, and I don’t need to adopt any changes he proposes that go beyond basic attempts to mitigate non-financial use of the block chain.

I’ve read the code Knots uses to identify spam - it’s not complicated and it’s disappointing that Core refuses to adopt any spam mitigation code Luke proposes or develop their own spam mitigation code.

The arguments from Core about spam are so naive despite many Core devs being incredibly capable that I think Hodlonaut might be right about how funding, incentives and centralized governance has captured the key Core devs. (e.g. fees paid to miners will price out spam even though the costs of spam are paid by node runners who don’t get paid and ~90% of mining revenue is the block reward not the fees; or spammers will do extra work to change their code so they can then pay 4x the fees to put their spam in pruneable OP_RETURN instead of continuing to embed spam in unpruneable UTXOs).