i tend to agree that a scenario exists where 'eventually' OP_Return limits should be relaxed, but in my head that scenario happens like maybe in a decade if a sustained effort to bloat the chain proves to exceed the desire for users to 'use bitcoin' far exceeding the efforts today or historically.

what is the acceptable limit of OP_Return? at what point is loosening the limit no different than removing it altogether?

what is your position on how new nodes on the network should be configured? should these limits (or lack thereof) be set in stone or allow some flexibility through configuration file like how it is done today.

while blocks occasionally (or arguably often) contain arbitrary data transactions that bypass limits set by node policy, those OP_Return transactions are only able to relay on a small subset of nodes on the network (proponents of removing limits often cite libre relay and some miners that accept out of band payments). whether or not there is an actual need for these larger op_returns i have no idea, but it would appear that those transactions have not been able to proliferate across the wider network of legacy nodes and have no way of expanding their use, this probes thay existing policy are effective. i havent seen an argument why new nodes should be expected to join the nodes which relax limits rather than the wider network which overwhelming enforce the limits.

anecdotally i run Core with the patch 28408 for about 18 months, and i send transactions regularly, my fee estimation has worked fine and ive been able to keep up validing blocks containing transactions not in my mempool just fine whether or not my peers include Bitcoin Knots, Libre Relay, or a peer still running v.15

utxo-bloat methods of storing data have only been tolerated on the network because it has been controversial to include those methods under current policy checks. if the concern is to address utxo-bloat perhaps that discussion should be opened up again and a clearer conclusion be made

I've no problem with:

"Allowing larger, standardized OP_RETURNs"

I've no problems having the default filter changed.

I object to having the filter removed so that someone can't easily but deliberately change it.

i like these points and sounds rational

I really dislike seeing people get blocked from discussion on github

its ironic that the discussion about 'censoring' (filtering) transactions gets censored

Do you think filters work? Because reading all this sounds like intellectual dishonesty for me.

Worth a read:

nostr:nevent1qqsv46dply4nca4frqr4z84qyt3qra2lajuutdku37suxsda20ptcacpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgsgclrrzfuhsh29pyxjn6nqqg9q0qtsq4lqmmelrqa9jj96haxpkvcrqsqqqqqphqxrvz

I’m against core blocking valid points of view from qualified devs.

I’m against giving up the fight to hamper arbitrary data inclusion into bitcoin.

I’m for giving individual nodes the right to choose their own filter settings.

Couldn't the same result be achieved -- over time with an option for opting-out, by doubling the -datacarriersize default with each future release?

It might leave the choice (at least the perception of choice) with the individual node runner.

It might offer the chance to learn over time that it is, or is not making things any worse.

It might not be so much different than node runners upgrading slowly.

It might not provoke node runners who are worried about this change to considering ditching bitcoin-core right now, many years before this merge would even make a difference (since many won't upgrade immediately).

Too much nuance in your take here. Nobody wants to discuss the actual issue. They just want to debate jpegs and ad hominem. Nuance makes people feel unsafe. Ignorance is peace.