Do filters work at censoring spam?

[PepeLapiu2]

When dealing with core supporters, you will often hear something like this:

Filters don't work because spammers bypass the filters and go directly to miners. The very fact that those transactions are confirmed proves that filters don't work at what they are intended to do.

The problem with this argument is that it grossly misrepresents how miners, nodes, and policy all work together.

The implication is that filters are put in place to censor transactions. And if those transactions still get confirmed, your filter didn't do it's job.

But nobody in the Bitcoin network is capable of imposing censorship. Nobody can censor anything. My node, with a pile of filters 10 feet high, can not censor anything or anyone.

In order to understand how filters work, you have to understand the role of nodes.

First, it's important to understand that there is no such thing as "the mempool". There is no centrally imposed standard mempool that anyone can impose on anyone else. Each and every node and miner in the network maintains his own mempool.

When you send a Bitcoin transaction with your wallet, that transaction gets relayed around to nodes and miners. Each and everyone of them checks that it's consensus valid and that it's policy valid.

If it satisfies my node's checks, it gets added to my mempool and relayed to other nodes. If not, I just don't add it to my mempool and I don't relay it to others in the network.

Now the role of my mempool is to send a signal to miners. My mempool says: "These are the transactions I have verified. You should add these transactions to your next block."

The miner is not obligated to listen to me. He can put whatever transaction he wants in his next block. But once he finds a block, and fills it with transactions, that block gets propagated to the network so that each node can add it to their own copy of the blockchain.

Once my node receives this block, I verify that the transactions in it are valid. If these transactions are already in my mempool, the verification process is very fast. Because I already verified most of them.

But if the miner filled his block with filth and spam that I did not include in my mempool, I have to request, download, and verify each of those spam transactions I have not already verified.

Only once this process is complete, will I add the block to my mempool and relay it to other nodes.

In simple terms, miners filling their blocks with filth will see the propagation of their block significantly slowed down. And they risk losing their block reward to an other miner who did not add junk and filth to his block.

Miners who take greater risks will have to charge more to their spammer clients to add their filth to their next block.

As you can see, it's a brilliant system with censorship resistance and incintives built in for each actor in the system  to act in a good manner.

The problem is not that filters don't work at censoring transactions. Nobody in the network can do that.

The problem is that there aren't enough filters. Miners are not receiving the signal from nodes that some transactions are not desirable. And this is because core refuses to build any filters, and core is even attempting to disable the filter that is already working.

But you don't have to believe me. You should just listen to Gloria Zhao, head developer at core, explain how block propagation works, at around 1:09:40 in this video:
https://youtu.be/VsUyjFkkp4E

Join the fight, run a Knots node:
https://bitcoinknots.org/

Edit: I guess a pretty good analogy would be to say that miners are in a race to find the next block and propagate it to the network.

Finding a block is like a bingo game.  If you have more hash power or more computers, you effectively have more bingo cards and you increase your chances of getting a bingo.

But than the propagation game turns your bingo game into car race. And each spam transaction the miner puts in his block adds a little speed bump in the track that pops up only for him. If he has a lot of spam, the track starts to look like a dirt and mud trail to him while everyone else is riding on clean asphalt.

Eventually the miner decides to use the same filters as the nodes are using in order to speed up his propagation time. Or he needs to be heavily compensated by the spammers to compensate for his race handicap.

[gmaxwell]

In simple terms, miners filling their blocks with filth will see the propagation of their block significantly slowed down. And they risk losing their block reward to an other miner who did not add junk and filth to his block

You keep repeating this lie then making a new thread when I point out it's a lie.

The effect of slowing down a block's propagation is not to hurt the creator of the block but to hurt smaller miners relative to larger ones.  If a larger miner produces a more profitable but slow to propagate block the large miner already has their slow to propagate block and so has a head start producing another one.  If a smaller miner produces one, the larger miners that don't have it yet are more likely to create a competing block that eventually beats the small miners.

[PepeLapiu2]

The effect of slowing down a block's propagation is not to hurt the creator of the block but to hurt smaller miners relative to larger ones. 

That makes absolutely no sense. If what you say was true, bigger miners would deliberately slow down their internet speeds or just delay propagating their blocks to sqash the small miners.

So which is it? Are you trolling, outright lying, or just don't know what you are talking about?

[BattleDog]

The claim that Core "disables" filters needs clarification. Core policy mostly sticks to standardness, feerate, and DoS limits, not content filtering. If your objective is to throttle high-fee junk, then the mempool policy won't do it alone as you'd need different fee economics or a consensus change at least.

[PepeLapiu2]

The claim that Core "disables" filters needs clarification.

Well, it needs clarification in that core can't disable filters (plural) because they only have one filter running and they are trying to disable that one filter. After a decade of watching spam get worst and telling us they can't do anything and gas lighting us with stupid claims like "the fee market will discourage spammers" and "we can't censor them" a lot of us were getting annoyed

That's until they tried to blow up the only one filter that's running. That was the drop in the bucket. I think core is done

I wasn't too impressed when a pull request suggested a raise from 80 bytes to 150 bytes. Core squinted really really hard and read 100,000 bytes. That's just f**king insane.

When someone suggests an ordinal filter, they dismiss it as "too controversial" and when someone suggests loosening a filter 2x they go ahead and try to loosen the filter 1250x. And that's not controversial?

Something's not right here. I don't know how anyone can defend core's behavior.

Core policy mostly sticks to standardness, feerate, and DoS limits, not content filtering. If your objective is to throttle high-fee junk, then the mempool policy won't do it alone as you'd need different fee economics or a consensus change at least.

Whatever it takes to get rid of spam, I don't think core is up to it. They have their shitcoin sponsors to cater to.

I'm running Knots with filters on. We'll see how that works as more nodes migrate out of shitcoin core. Than if the filters are not enough, we can look at your proposal. Deal?

[BattleDog]

Firstly, Bitcoin Core doesn't have "one filter." Relay policy is a bundle of resource guards: standardness checks, feerate floors, ancestor/descendant limits, sigop and weight limits, RBF rules, etc. They exist to keep nodes stable, not to classify content, so changing one constant isn't "disabling filters," it's tuning DoS trade-offs.

And second, the relay policy can't "get rid of spam" by itself. Miners include high-fee transactions even if many nodes won't relay them, and big pools use private peering and fast relays. That makes policy an economic nudge, not a censorship switch.

Running Knots with stricter rules, I'd say, is a valid experiment, though.

[PepeLapiu2]

Firstly, Bitcoin Core doesn't have "one filter." Relay policy is a bundle of resource guards: standardness checks, feerate floors, ancestor/descendant limits, sigop and weight limits, RBF rules, etc. They exist to keep nodes stable, not to classify content, so changing one constant isn't "disabling filters," it's tuning DoS trade-offs.

You have to be kidding me. Blocks are filled with absolute shit. In all the filters you listed only one is geared at preventing spam, and core is trying really hard to disable it. And you try to te me they are not doing it to enable spam but to keep me safe from DoS attacks?

Jesus man! Even core claims that op_return is a less harmful way to spam and they hope the spammers will use that instead, and you find a way to claim it's not about spam?

And second, the relay policy can't "get rid of spam" by itself. Miners include high-fee transactions even if many nodes won't relay them

How would you know that? As it is, nodes are being forced to relay absolutely everything due to core's lack of filtering.
There is however one single spam filter that is in place - the op_return filter which is still at 80 bytes on probably 90% of the nodes. And it works remarkably well at what it does because over 99% of op_return transactions are under the 80 bytes limit. Which proves that the filters work, if enough of us run them.

and big pools use private peering and fast relays. That makes policy an economic nudge, not a censorship switch.

I'm well aware that filters can't censor anything, thank you. Here is a thread I wrote explaining how filters work:
https://bitcointalk.org/index.php?topic=5562641.0

Running Knots with stricter rules, I'd say, is a valid experiment, though.

I would go even further and suggest that running Knots is the only way to save Bitcoin from an obvious attack.

[BattleDog]

OP_RETURN's 80-byte cap "works" because wallets conform to relay policy, which shows that policy nudges behavior, but it doesn't prove policy can eliminate paid traffic. If a tx bids enough, pools will take it even if only a few peers relay it.

"Core has one filter" just isn't accurate, I'm sorry. The things you call "not spam filters" are exactly what shape the network: feerate floors, ancestor/descendant caps, standardness, RBF, weight/sigop limits. They protect nodes and indirectly price out junk. Content filters for inscriptions are brittle anyway, taproot can re-encode payloads in endless ways, so you end up in whack-a-mole.

Knots with stricter policy is fine, but it only changes outcomes if miners adopt it.

[PepeLapiu2]

OP_RETURN's 80-byte cap "works" because wallets conform to relay policy, which shows that policy nudges behavior,

Yes, I partly agree but you are putting the buggy ahead of the horse here. You need to understand that wallets have it set it because wallets know an op_return with 100 bytes would cause problems for the miners who put it in their block.

but it doesn't prove policy can eliminate paid traffic. If a tx bids enough, pools will take it even if only a few peers relay it.

Nothing, absolutely nothing in the Bitcoin system can completely eliminate something. Because that would be censorship. And Bitcoin can't do censorship. Filters are not a form of censorship, they behave more like a speed bump.

When they speed in front of your house, your kids and your pets are put in danger. But when they speed in front of my house with speed bumps, the speeders pays the price with a torn undercarriage. Filters work in a similar way in that they make it more painful for miners to accept spam. I suggest you read my thread here to understand how filters work:
https://bitcointalk.org/index.php?topic=5562641.0;topicseen
.

"Core has one filter" just isn't accurate, I'm sorry.

I should have been more precise. Core only has one spam filter, the op_return filter. Yes, there are other filters, but not for spam. They only have one spam filter and they are working at getting rid of it.

The things you call "not spam filters" are exactly what shape the network: feerate floors, ancestor/descendant caps, standardness, RBF, weight/sigop limits. They protect nodes and indirectly price out junk.

If you think those filters are pricing out junk, you need to have a look at the mempool lately. It's full of junk. Those filters are doing a very poor job.

Content filters for inscriptions are brittle anyway,

How would you know? Core never tried them. They have never been deployed on any significant scale. But Knots nodes are working to solve that problem.

taproot can re-encode payloads in endless ways, so you end up in whack-a-mole.

This is the defeatist bullshit we have been fed by the shitcoiners for the last 8 years. The assumption is that if you lock your door, some intruders will break the window, so you might as well open your door and cook a meat for them while they steal your TV and rape your wife.

Knots with stricter policy is fine, but it only changes outcomes if miners adopt it.

Yes, but that is the equivalent of saying the speed bump only works if the speeder adopts it. Please read the thread above that explains how filters work. And try not to pay too much attention to those who will try to tell you I'm a stupid censorship nazy who strangles cute puppies on Sundays.

We can never get rid of jpegs and other spam completely. That would be censorship. But we can create incentives that would make most of them not want to spam on Bitcoin, and move on to shitcoins.

Edit: I just realized I'm linking to the same thread I'm writing in. Sorry about that. I'm not very smart, I get by on my looks alone. I just cant figure out why girls laugh when I say that. 😁

[PepeLapiu2]

This needs a post on it's own because it's just too good.

OP_RETURN's 80-byte cap "works" because wallets conform to relay policy, which shows that policy nudges behavior,

This should tell you that filters work very well. They work so well that wallets build around the policy and that is likely because miners absolutely want nothing to do with non-standard over 80 bytes op_return. They know it's going to cause them problems.

This shows you that filters work.

What we need is more filters, not less.