I guess I am starting to come around, here's my understanding..

Even if long-term demand for nonstandard transactions does not meaningfully materialize (as I claim it won't), the present set of actors (whoever it is and whatever they are doing) will be contributing a centralizing influence on miners because larger ones can claim the fees of confirming these transactions without eating the slippage from excluding other, standard transactions instead. They can reasonably expect to get the transactions confirmed quickly.

Removing any OP_RETURN limitations removes the mining influence immediately. It still remains cheaper to use witness data in general, so the additional pressure for data anchoring that is introduced by OP_RETURN is minimal.

I still don't know how I feel about removing configurable policy.

I understand the argument for this specific case, but in general? Especially for something like bitcoin.conf which we've both conceded will only be altered by enthusiasts. How many options should be done away with?

Reply to this note

Please Login to reply.

Discussion

In general, my view is software shouldn’t have options that let you shoot your foot off, even accidentally. Even if you can live fine without a foot, you probably prefer to have it.

For relay policy, divergent rules tends to be that. There may be some exceptions (like “I have little CPU power and can’t process complicated packages of transactions” or “I have little memory and want a smaller mempool” or even “this may get used in the future but it isn’t now so have an option so people can enable some new transactions without upgrading”), but in most cases divergent policy is simply divergent policy, and only harms the user”.

Thank you for taking the time to discuss

Thank you for asking good questions!