To be clear, this won't permanently censor these transactions either, but because not everyone is going to be sufficiently intimidated. But it will delay them more than in the scenario where those miners only exclude things from their own blocks. And definitely delay them more than can be achieved with just policy, even if 90% of nodes used these filters.
Discussion
As the reference implementation, core should have “the best” policies from a genuine comp sci and networking perspective, not a commercial one.
Any major policy decisions should be handled at the fork level. Want more data carrier size? Fork it! The thought that this should be debated on github is laughable.
I would recommend Greg Maxwell and AJ Towns latest replies on the mailinglist. It's harmful if people use different settings, whether that's by configuration option (-datacarriersize) or by code forks (Knots). The chaos of a "free market" for settings is disruptive for the network, which only helps its real adversary: governments.
The custom Knots default of 42 bytes caused problems in the past for Samurai wallet (which they in turn used for their drama marketing). In theory it should also interfere with compact block relay (I haven't seen measurements though).
https://gnusha.org/pi/bitcoindev/aBSVn7nJnrheLy5Z@erisian.com.au/
It’s tricky to parse what disrupts the network from relay and miner perspectives. I can see a miner having to validate a block with transactions it’s never seen before to be a disruption, but for non-mining nodes I don’t see it as a problem.
For non-mining nodes, relaying/accepting transactions that won’t get mined certainly doesn’t make sense; nothing-at-stake mempool attacks are an obvious consequence.
All that said, perhaps the real issue here is analogous to the misaligned incentives leading to Napster: people wanted downloadable music and there was only one way to get it. It wasn’t until music companies stopped suing would be customers and started selling digital music did the issue go away.
With regards to what I said here:
> This then encourages them to be on the safe side and use these filters. Bitcoin Core might then have to adopt similar rules in order to produce blocks that are safe.
This would be a "nice" use case for what Greg Maxwell suggested today on the mailing list (and earlier on Reddit), to separate relay policy from mining policy - where the latter can be more strict:
> That said, Bitcoin core has generally not
had knobs to adjust relay policy as distinct from mining policy in large
part because of the design assumption that the two need to be the same.
But in this case if there were a knob here I think would make more sense
for it to control mining policy rather than relay policy, since it would
actually have some effect in the mining context (in excluding the txn from
your own blocks) while as a relay only thing it is impotent.