I don't understand how smart technical people believe it's possible to prevent spam through static filtering rules.
I. Just. Don't. Understand it.
Login to reply
Replies (74)
It’s a stopgap
I also do not see why existing restrictions must be removed.
"FIX FHE FILTER!!!"
The filter:
I don't understand how smart technical people believe it's possible to prevent spam through static filtering rules.
I. Just. Don't. Understand it.
View quoted note →
Some people never managed email servers and spamassassin rule sets and it shows.
It's like, you gotta believe in something right?
If people understand the reason of rules, everything is all right.
it's not, just another prevention mechanism
It doesn't prevent spam
What is spam?
yeah
If it could be stopped, we'd be fucked
Ecash rate limits spam
We just got a pretty sweet AI service at work.
It just works, with minimal management.
maybe they aren't that smart...
or just haven't thought it though...
That sounds like a strawman to me. The start of the dispute was a PR to update datacarrier size to consider Taproot. Furthermore, I haven’t heard claims that spam would be prevented, only mitigated.
it works
Email servers never gave up fighting spam, which can’t be said for Bitcoin unfortunately.
Maybe you’re not that smart yourself.
Exactly, and that’s the entire narrative of the spam apologists: we can’t score a definitive win against spam, so we should abandon the fight entirely. To me, these people expose themselves as either intentionally dishonest or bad actors.
After hearing both sides over the past 10 years, I’ve come to believe this isn’t really a technical debate, it’s an ideological one.
Open relays are currently up and running and have been for many years, so experience tells a different story.
As long as the cost to attack is higher than the cost to defend, they can survive.
it’s not about full-stop prevention, it is about allowing choice to node runners, keeping incentives aligned for monetary transactions (no reason to make clearly identifiable spam easier), cultural norms in development and discussion surrounding interventionism in the code base.
please tell me wherever I am wrong
not to mention the conflicts of the people who are spearheading the discussion for the “pro-PR” side
oh maybe you where talking about Bitcoin and not what I posted... ups
that's it right there. they don't want you to have the choice. Bitcoin knots lets you choose your mempool policy.
setup lighting wallet mr meth so I can zap
Not giving up against spam is good because anti spam technologies enabled Bitcoin in the first place. Thank you @npub1qg8j...24kw et al.
Guy, it's like asking "I can't believe how any smart people could think that cops can stop all crime!"
That's not the claim. It's that filters enable your miner to select transactions YOU want to include. That is literally it. And by the same logic "if everyone followed the law, there would be no crime" is the same as the filter contention. But if MOST people filtered there would be LESS spam because of the sheer popularity of filtering. It's not a mandate, it's a consensus. Right now there is no dominant consensus.
I hope this helped you understand.
The comparison doesn't work because there are significant negative consequences to the person doing the crime if he gets caught while there are practically not significant negative consequences from having arbitrary data caught as such.
Even if it worked as you say it has significant negative consequences if people bypass it creating UNPRUNABLE data.
Yes, we already have transaction fees.
Ah, so you don't see centralization of a financial network as a problem? But like so many of these analogies they are not 1 to 1 comparisons or else I would just state the situation at hand instead of contriving a similar situation to illustrate a point in more understandable terms.
"Apples are sweet and delicious"
"That's like saying oranges are sweet and delicious"
You: No, it's not because oranges have a different nutrition profile from apples.
Spam is unprunable data by definition. It goes directly to the UTXO set that has been so bloated in the past two years alone it has basically bricked the low end node hardware devices.
It's not a strawman. Static content filters do not mitigate spam on the blockchain at all.
To continue the police analogy, to reduce spam you need actual deterrence in the form of very serious real cost. Such cost should ideally be imposed on the spammer or on the miner that facilitates the spammer. The former would require KYC. The latter can be done. But be careful what you wish for.
> If development were primarily about choice the developers ought to instead just ship a copy of GCC: there tada, you get all the choices, write your own node. :)
/u/nullc
Jokes aside, it's a good post.
https://old.reddit.com/r/Bitcoin/comments/1kab15o/bitcoin_cores_github_mods_have_been_banning_users/mpou6xb/
View quoted note →
Meant to link to a later post in that thread:
The most effective way to encourage significant censorship by all miners is to credibly threaten them with reorgs if they include bad things. Needless to say, that would set terrible precedent and probably be the actual end of Bitcoin.
View quoted note →
View quoted note →
Did you read the mailinglist thread where this was explained?
[bitcoindev] Relax OP_RETURN standardness restrictions
> I don't understand how smart technical people believe [X]
Unfortunately this is completely normal human behaviour (which I don't pretend to be immune for, but I try).
Honestly honoured by your response and love your podcast.
I was not arguing for or against the effectiveness of filters in my post. I’m saying that @Luke Dashjr and co want filters that change over time, not **static** filters. Representing the contrary IS a strawman.
Police don't prevent any crime, they actually increase crime rates.
So I don't think it's a fair comparison unless the spam filter is actually increasing the amount of spam.
You can't change consensus on a whim. Standardness filters don't work. But even if they did, Bitcoin Core does a release once every six months and people can take years to upgrade. Spammers can adjust because the release is even out. So for all intends and purposes these filters are static.
Now you add a privileged public key to each that accepts new filters in real time. Then they wouldn't be static. And then OFAC asks for the corresponding private key.
* before the release is even out
Perhaps we could implement a proof of work to prevent spam on the chain. Oh wait...
Okay, perhaps one of several reasons why filters may be ineffective is that they cannot be changed fast enough. And, dependance on constant updates is a potential attack vector. It is still a stretch to describe the position as wanting static filters. And automatic updates by a trusted party would be crazy. Nobody of any note is talking about that or changing consensus - another strawman.
The meta point is that misrepresenting the other side’s arguments (i.e. straw manning) is not an effective strategy for persuading informed fence sitters. That is true even when you are right about the specific issue at hand.
Lol, I mean I would say even as an anarchist, police reduce crimes by people in a community. Police committing crimes is another issue but also it would be speculation to assume a net increase or reduction in crime in the absence of police because private security does not have enough sample size versus the state police sample size.
REGARDLESS of ALL of that my point was that you don't remove the option of defense, in a voluntary association.
@Guy Swann gave a better analogy using a fence to explain the conflict here.
Every time I say anything about the issue, someone tells me I think filters will stop all spam, even though I’ve never said it once, and have said the opposite on many occasions
Hashcash ... PoW 😉
I'm happy to give @calle some artistic license here. It's also worth considering that the people who advocate for filters do not have a clearly articulated position. That includes a lack of clarity about how far they're willing to go. Is the line really at automatic updates? Just because nobody said it out loud? The arguments in favour of filtering seem to vary by who you ask. So that means any attempt at summarising the position can be interpreted as a straw man by someone who has a slightly different position that the other person.
You could advocate for preventing easier spam on Bitcoin — but instead, you’re advocating a change that enables it further. How about leaving it alone? You’re proposing a major change, so the burden of proof is on you. We’re not obligated to follow, and we won’t.
Consequences for the person doing it.
If you steal a car and get caught you're going to prison on top of other problems.
If you send a transaction with data hidden and get detected/rejected, you've just wasted time constructing such transaction and that's all. No prison, no fines, no destruction of reputation.
Okay dude, have fun with that brain you have.
Leaving it alone incentivizes WORSE spam - flooding UTXO set!
OP_RETURN doesn't need to be in UTXO set but the fake outputs trying to bypass the 80B limit do.
One man’s artistic license is another’s strawman. In discourse, speculating about what position your interlocutor might hold in the future with no evidence whatsoever to back it up - a.k.a. mind reading - is a close cousin to straw manning.
Leaving the limit alone I mean. I’m not advocating ossification. I’m advocating a conservative approach when it comes to the changing the Bitcoin code.
The pull request links to a mailinglist post that explains all of this. You're not required to read it, but this "burden of proof" has been more than bet. On the flip side, those who oppose the pull request have not raised a single technically valid argument. And rather than just running Knots, many of them choose to harass developers and frustrate the Github repo.
* met
This is survivorship bias that valid arguments must only exist in their domain where they have the power to censor.
How convenient that you don't have to read anything!
Yes where I have a voice too.
Removing this limitation to enable BitVM or Citrea’s bridge doesn’t count as “proof.” As a node runner, I refuse to go along with changes that risk corrupting Bitcoin Core.
It’s arrogant to assume all risks have been accounted for. Just look at how Taproot unintentionally enabled spam via Casey Rodarmor’s Ordinals — a scenario developers didn’t foresee. That alone should be a cautionary tale.
The so-called “proof” in the mailing list isn’t convincing, and I’m far more concerned about the unintended consequences that often follow well-meaning but poorly considered changes.
Its the opposite. You suggested censoring people which is a form of harassment - first screenshot.
People gave you numerous technical problems with this PR and you were not able to give appropriate argument of why it will be good for Bitcoin network - second screenshot (and there are many more technical comments in the pr discussion although many were silenced like the Bitcoin Mechanic)
Not really, the limit is actively harmful to bitcoin.
Would be interesting to see a response to this @Sjors Provoost?
Why would the spam stop when it is not left alone?
If you want to know why this pull request is very bad for Bitcoin you can watch the Bitcoin Mechanic video who was banned from the GitHub discussion for pointing out that sharing a conflict of interest is not against the rules of the discussion.
> You suggested censoring people which is a form of harassment
It's complete nonsense and I don't have time to engage bad faith actors like "BitcoinIsFuture".
It was already multiple times on that pull request that conceptual discussion needs to happen on the mailinglist. Yet people ignore that instruction. And as I predicted, they kept doing so.
When people break into your office and start screaming at staff, sending them away is not "censorship".
* already stated
People want some options for deterring spam, like making it more cost prohibitive.
Observing spam & coming up with some solutions that mess with their efforts shouldn't be dismissed.
The whole energy around this mess just proves one thing:
Core devs haven't had to deal with the free market in quite some time.
It's time.
💯
The consequences are either being prevented outright since filters *do* prevent some spam, or getting charged more to include the spam.
Both work to reduce it
"Bad faith actor"? Look in the mirror. Clown🤡
We have consensus rules. Nothing you say makes anything more cost prohibitive. They will just use Taproot outputs.
Regardless of opinions on this exact issue, core devs need some pushback & Bitcoiners need optionality.
I think this energy for example is abhorrent:
Excellent take by me! :-)
The fact that many Bitcoin Core developers are paid by someone, when that someone is NOT YOU, does not make YOU a customer that gets to demand things. You need to hire developers directly if you want to work on your behalf.
View quoted note →
View quoted note →