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.

nostr:nevent1qvzqqqqqqypzpp59a0hkv5ecm45nrckvmu7pnk0sukssvly33u3wwzquy4v037hcqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgewaehxw309ahx7um5wgh8xurjdamx7mmnwshxump0qqsxf0td3urgpp95yzszh9y9ewhyxz2eggnfnrzg856wl6xk6nxf7gslakzjv

Reply to this note

Please Login to reply.

Discussion

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 nostr:nprofile1qqs0m40g76hqmwqhhc9hrk3qfxxpsp5k3k9xgk24nsjf7v305u6xffcpzamhxue69uhhyetvv9ujumn0wd68ytnfdenx7tcpzfmhxue69uhkummnw3ezucn4d9kxgtc2nych7 and co want filters that change over time, not **static** filters. Representing the contrary IS a strawman.

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

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.

I'm happy to give nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg 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.

Leaving it alone incentivizes WORSE spam - flooding UTXO set!

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.

Not really, the limit is actively harmful to bitcoin.

Why would the spam stop when it is not left alone?

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)

Would be interesting to see a response to this nostr:nprofile1qqsgdp0taan9xwxadyc79nxl8svanu895yr8eyv0ytnss8p9tru047qprpmhxue69uhkummnw3ezuumswfhhvmm0wd6zumnvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqejfhn?

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.

https://www.youtube.com/watch?v=15biQH1H140

> 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

"Bad faith actor"? Look in the mirror. Clown🤡

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.