Quote from: aphetor on May 15, 2025, 09:03:53 PM

I just wanted to post my thoughts somewhere and share a relevant anecdote from bitcoin++ last week.

Thanks for your comments!

Quote

Regarding point 1, the question to me is what exactly constitutes <arbitrary data>? All data that is not directly related to spending coins? Should all arbitrary data be considered spam? Isn’t spam subjective?

I heard Luke Dashjr’s respond to this last question, “No, there’s an objective difference. Bitcoin’s design allows miners to include up to 95 bytes per block of arbitrary data in the coinbase. That is completely different from spam which is encoding this arbitrary data to look like something it is not to deceive nodes into accepting it. If you submit a JPEG as a transaction it will be rejected by every single node. You have to obfuscate it and make it look like something it’s not to make it accepted.”

That really to me sounds more like luke-jr justifying his historical practice of putting bible quotes and other bitcoin-irrelevant material in blocks. I don't think it really answers anything. There are many fields in Bitcoin -- like the entire content of the output scripts of a transaction that the consensus rules don't do anything with, just like the consensus rules don't do anything with the scriptsig of a coinbase transaction (the '95 bytes' the reply refers to). I've seen no indication that the anti-spam contingent is okay with stuffing arbitrary data into *those* fields. And it's probably worth remembering the the history of Bitcoin "anti-spam" started with Satoshi dice an "on chain gambling site" (really probably a money laundering operation (see the first and second MTGOX hacker indictment, and dooglus' forensic accounting), but it at least pretended to be a gambling site-- history may not repeat but it rhymes). Luke created, ran, and distributed patches that blacklisted their addresses and even put the patches into the gentoo distribution of the Bitcoin software, not just his own knots.

So even if we go back to the very start of anti-spam in bitcoin we can see that it has always hinged on a subjective judgement of the users activity. The Bitcoin project (now called core) has always eschewed that sort of thinking and tried very hard to make any restriction as content neutral as possible-- even when, or especially when, the contributors didn't like the usage.

At the same time that answer also strikes on why filtering efforts are pretty doomed-- he starts by assuming that the user is willing to disguise their activity as something it isn't. But that same willingness is why it can't be blocked, or at least the portion of "spam" that really is disguised.

I think in general the term spam is a poor fit. With email spam you win so long as you don't see it, it doesn't matter if your computer sees it or your ISPs computer sees it. And all this stuff in bitcoin that gets called spam is never seen by anyone who doesn't want it, so by the email definition bitcoin has (almost) no spam. There is ONE thing in Bitcoin that is very much like email spam: Dusting. And yet dusting wouldn't fit in the definition above, as it's not disguised as something it isn't. It's a payment, just one that you don't want and probably causes you more harm than good. There is a fair amount of dusting, it seldom generates much complaint. There are things that can be done to deal with it (e.g. wallets not showing the small payments)-- but it seems there isn't much interest in trying. So I think there is an issue, sure, but spam isn't the right word.

Similarly, op_return traffic isn't disguised. But clearly no one is arguing that it is definitionally impossible for OP_RETURN material to be spam.

I think the thing people are actually mad about today is shitcoin issuance and the fact that people are willing to burn up Bitcoin's capacity on tokens whose value is essentially independent of Bitcoin. But none of the anti-spam stuff really addresses that, and to the extent that the shitcoin stuff is made more valuable by limited supply, it might even make it worse.

Quote

Regarding point 2, given that Bitcoin Core is the default client used by the vast majority of nodes on the network, removing the datacarriersize limit, would make it more difficult for Core nodes to *easily* limit the size of the op_return field. I take Greg Maxwell’s point here that there is some “serf thinking” involved in that Bitcoin Core does not give you these rights. The Bitcoin Core client is an open source tool that you can choose to patch, fork, and modify as you see fit. I think the defenders of the op_return limit are interested in the *ease* with which someone can make a decision in one way or another. In any case, I’ll leave my conclusions below my story below which I think is a nice illustration of the debate.

I'd agree except for the fact that isolated participants setting that setting don't actually have any beneficial effect to themselves. I don't think the easy of an ineffectual choice is a relevant development criteria. There is a real cost to users and developers in having more options, and the software shouldn't offer knobs that essentially don't work. In any case, at least for now it looks like the knob is staying.

Quote

There was a project called GarbageMan presented at the bitcoin++ hackathon that forks a Knots node to impersonate a Libre Relay node by setting the node’s service bit to signal to other Libre Relay nodes that it is also part of the Libre Relay network (bit number 29). These Knots nodes, pretending to be Libre Relay nodes, prioritized Libre connections as their preferred peers. This way the “Garbage Men” could infiltrate the Libre Relay network to intercept transactions the Knots nodes consider spam, and throw them away. (Prez: https://www.youtube.com/live/cLLpmbg4KKk?feature=shared&t=2277)

This was an awesome project and clearly a fun jab at Peter Todd, who was one of the judges, the creator of the Libre Relay project, and also who opened the original PR to remove the datacarriersize limit.

I mean it's a sybil attack and probably a CFAA violation, though obviously no one is going to be pressing charges over it. If anyone cared about it, it's easy to bypass, by simply observing the peers behavior and banning peers that are clearly filtering transactions or going farther and periodically asking peers how much the next block is worth, fetching it if they have something more valuable, and banning them if they can't deliver.

Bitcoin Core already does this for blocks-- basically testing the peers accept the chain they're on, and disconnecting ones that don't and also by slowly probing the entire network to make sure no one has a better chain. This was implemented because of a similar "pretend to be compatible" behavior put into segwit2x as part of an effort to force nodes into accepting a hardfork by surrounding them and denying them access to a chain they were compatible with.

Librerelay itself mostly seems to be performance art, pointing out that censorship is substantially undermined by even a small amount of parties being willing to route around it. The point really isn't defeated by an attempt to undermine librerelays rather minimal and half-hearted efforts... and you got to kinda wonder what people are thinking there? Because while Librerelays point is that censorship is ineffective, the counter's argument is that they can make it effective by trying harder. Is that really where we are? With supposed Bitcoiners arguing that censorship is effective and cooking up better roadmaps for trying it?

Bleh.

(And sure, I'm aware of the position that the filtering isn't censorship due to some value judgement over the usage, but the tools and methods are the same...)

Quote

Peter Todd’s argument was that filters would be ineffective on the mempool because you could just use services like Libre Relay to get around those filters. GarbageMan is a strike back that filters could be deployed to attack the Libre Relay network as well.

Of course, fixing librerelay to punt the sybil attackers takes some code and Peter Todd is not likely to waste too much time on his performance art... But the more fundamental point is that you can (and today the 'spammers' largely do) just give the transactions directly to large miners. This is just horrible for mining centralization, and at least librerelay was a little corrective pressure against direct miner relationships.

I'm very saddened that people's thinking has become so distorted and in favor of blocking stuff that they don't like that they're cheering what is effectively a sybil attack against an effort that bypasses blocking to avoid creating direct miner relationships. I'm really glad that Petertodd is a good sport and views that sort of thing as just another interesting challenge.

Quote

Finally, if the real issue here is the spam, It seems the only way to definitively filter or block this would be through consensus rules changes or through centralized or homogenized block template creation. If block template creation is more distributed then you’re more likely to have people who mine non-standard transactions and it’s more difficult to gain a majority of mining nodes to only accept block templates of certain characteristics.

Indeed.

Quote

Bitcoin’s blockspace is a free market. I think people can and will express their political positions through their nodes, but that it is not Bitcoin Core’s job to outfit them with those tools.

Bitcoin nodes are all about making a statement about what Bitcoin is by literally defining it via their consensus rules. During the whole blocksize war drama there were a lot of people who just didn't get that.
Part of why they didn't get it is that they were focused on another truth: When it comes to what Bitcoin does *within those rules* those nodes have little to no influence unless they are mining, and even if mining they have the power to permit without the power to refuse. The power to refuse comes only from a supermajority hashpower and/or consensus rules. And this is a point that I think today's hyper-bitcoin anti-spam advocates are missing.

The situation would be different, perhaps, if the anti-spam army were proposing consensus rules-- but so far they haven't, and that is no shock because there isn't any rule consensus or otherwise that blocks traffic that doesn't need consensus enforcement and is willing to change its appearance (well not any short of radical changes that would cause massive functionality loss). They stick instead to policy rules, which at least allow for a perpetual ineffectual game of cat and mouse. One I think might provide for full employment for filter authors and filter evaders, but be no good for the rest of us.