What about inscribing sovereign identity proofs like domain ownership?
Did you not create this tool to do just that? https://supertestnet.github.io/inscriptions-online/
I created that tool to illustrate how spam works, to teach people how to filter it, and to trick inscription fans so they would stop running nodes. I don't recommend using it to crate inscriptions on mainnet, but go for it on testnet
> there are protections in bitcoin against many types of attacks against real DoS vectors. Op_returns don't present such a threat. If they did, miners did not have an incentive to mine them
This seems to be the heart of our disagreement. You say spam doesn't present a threat similar to a DoS vector; I say they both cause serious harm, but spam does so more subtly and more slowly. This article by Chris Guida outlines why: https://x.com/cguida6/status/1968117953871720463
As for why miners continue to mine spam, that is the golden goose problem: financial incentives can cause miners to slowly and subtly harm the goose, a knife cut at a time, to get the golden egg more quickly. But the goose may die by a thousand cuts. It is part of why I personally want to eliminate spam from my mempool and slow down blocks that contain it -- to provide a counter financial incentive so that miners will reconsider whether they should mine it or not. And it is also why I invite others to join me in the effort
Chainspam is any data in blockchain txs not there solely to transfer, reclaim or privatize value securely. Transfer = reduce the senders' amount & increase the recipients'. Reclaim = restore part/all the senders' amount after a failed payment. Privatize = do a coinjoin or similar
> What about the consequences of slower verification of blocks for the whole network of nodes
Only blocks containing spam are delayed. This is a desirable outcome because it provides a monetary incentivize for miners to ignore spam.
> The fee estimatiom problem is also a well-known predictable effect of purging mempools this way
It is not a problem because nodes don't look at the mempool when estimating fees.
> Yet another serious issue is to burden all nodes with substantially more validation _for ever_ with inscriptions in pubkeys. In contrast, op_return can be ignored in validation.
I personally think the "cure" (raising op_return to 100kb) is worse than the disease. Very few protocols store data in pubkeys. The ones that do are unpopular and rarely used. Storing arbitrary data on the blockchain is a significant abuse of the blockchain, and relaxing op_return will, I suspect, invite even more of it, thus doing more harm than the comparatively small problem it supposedly fixes.
> If you store "spam" in RAM until it gets mined you avoid having to redownload and cryptographically verify the "spam" tx once it gets mined into a block
Sure, but in the meantime, your memory is free for uses better than storing and relaying spam. I am reminded of the man who said he wouldn't shave because it just grows back again. That's fine as a personal preference, but the alternative tradeoff makes excellent technical sense: at the cost of downloading a few kilobytes later, you reduce the spam in your mempool and provide miners with a monetary incentive to not make spammy blocks (that incentive being faster block propagation).
> I would not agree that disk space is abundant. You can get by with just 300MB RAM for an unfiltered Mempool and don't have to upgrade RAM however many noderunners will soon have to upgrade from a 1TB SSD to a 2TB one which is a cost factor and also implies manual effort and downtime.
Interesting use of the phrase "you can get by." You can certainly get by without upgrading your mempool, but you can also get by without upgrading your hard drive, by pruning.
> Unless one believes they have been compromised then there’s nothing to worry about from them
I don't think you (or anyone) means this, but in case anyone thinks that the only motivation to use knots is thinking the Core devs are compromised, there is absolutely another motivation: simple disagreement with their software choices. They've chosen to set the spam filters to certain values and stated their reasons for doing so. Without any ill will, one may simply prefer to set different spam filters and therefore adopt software that does so.
> Spam is subject to semantics
In a bitcoin context, it is also subject to definition: chainspam is data embedded in blockchain txs not there solely to securely transfer, reclaim, or privatize value. Transfer means reduce the senders' amount and increase the recipients'. Reclaim means restore part/all of the senders' amount after a failed payment. Privatize means do a coinjoin or similar.
> If we cannot create an algorithm that gets rid of 100% spam for everyone, than we simply don't know what spam is for everyone
It may be possible to express the above definition in one or more algorithms that together filter all spam except possibly for spam requiring off-chain disclosure of a deciphering key. But even if not, there are algorithms that eliminate entire classes of spam from user mempools; they are in use in Knots, for example. One need not have a 100% effectiveness rate for the filters to be useful.
> we must not give in to our urge to censor people we fervently disagree with
Interesting choice of the term "censoring." Why is it wise to filter DoS attacks? Because users find them harmful, regardless of whether the attacker feels censored. For the same reason, it is wise for users to filter any spam they don't want in their mempools, regardless of whether the creator feels censored.
It was Citrea, and AFAIK they plan to use utxo stuffing only if a bitvm contract is challenged. This is designed never to occur, as it requires someone to manually create and submit a "cheating" bitvm transaction, whereas "honest" bitvm software is designed to try very hard not to let you do that.
Besides the disincentive of manual work, it also carries a huge monetary disincentive: your counterparty in the bitvm contract is meant to be running software that automatically detects cheat txs and responds by taking all of the money the cheater put in the bitvm contract. (It works a lot like a lightning penalty tx, but more complicated because bitvm is complicated.)
Despite being designed never to occur, this potential for extremely rare utxo stuffing by one party has been leveraged to relax the op_return limit for everyone. Which I think is silly.
My favorite part of today: I observed that in the Knots v Core debate, the Core side leans on emotion and the Knots side leans on technical/logical arguments
Immediately, Core supporters responded with ridicule and ad hominem -- i.e. appeals to emotion
> Not one answer for the fact that I keep posting that knots real solution is that they are making Cloudflare scanning a defacto part of Bitcoin by insisting on a solution that makes all large op_returns MARA and trusting their scanning slipstream submissions
The knots solution does not make *any* large op_returns MARA
The knots solution simply filters large op_returns from your own mempool
If a spammer therefore submits the large op_return to MARA that is not knots' fault, and if MARA mines it, that too is not knots' fault
> ocean, datum, and knots are the best way to put CSAM on chain before core 30
How so? I am not familiar with this claim
yes
for the reasons given, "thinking of the children" is a perfectly legitimate thing to bring up in a technical debate
it immediately counters the statements/challenges mentioned and instantly illustrates a central tenets of the pro-filter position: that spam is harmful
> And there is no way to get there but a think of the children?
It is a fast way there, and efficiency is very usefl
> It is an argument designed to destroy rational thought
Rather, it is an argument to focus it
this, friends, is another appeal to emotion: the classic ad hominem
when a sophist has insufficient logical or technical support for his arguments, he often resorts to insulting his opponents
emotionally needy people don't want to identify with the maligned by getting on their "side," so they can be swayed to side A by insulting side B
doublespend protection is not guaranteed unless you check for doublespends
if you don't check for them you are relying on someone else to check for them
if *no one* checks for them then doublespend protection is not guaranteed
Right, the team shouting CSAM every post aren't playing an emotional approach.
https://www.age-of-the-sage.org/psychology/social/hastorf_cantril_saw_game.html
there is an excellent technical reason to bring up CSAM: it is a clear example of why spam is harmful, which is a principle tenet in the fight against it. Very often our ideological opponents say "there is nothing WRONG with spam" (e.g. here: nostr:nevent1qvzqqqqqqypzqf42cz6fz5vk4t22w8hrqdpe7verglllzesnjzv7yh5jchhc0k2eqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyr4s0ts4kgrntp8wq2e8wsavnpang24mcedypzpdz9aseul4n6x5svpncsk) or issue challenges like "you can't DEFINE spam" (e.g. here: https://x.com/L0RINC/status/1967404819716694518)
CSAM is an obvious way to counter these statements/challenges
notice how instead of refuting my example logically, Calle wants to bring you to his side through ridicule. This is a classic example of sophistry: 
Plebs lately: "Wow you listen to @mattkratter too?" https://video.nostr.build/81b617b2570e7803973a29ea49fadb49707f9802d94b144707b502d83b572c6b.mp4
yes, the Core side appeals to authority a lot
however, the appeal to authority is not fallacious, it's just typically a weak argument, as the authorities might be wrong
in this case it's particularly weak because the authorities disagree