No change. I don't see what we have now as problematic enough to warrant any changes. If Core were to implement a change I would want it to be user configurable with the default being what we have now.

Increase to 256 bytes.

This distracts from the actual problem of P2MS spam. No one sane will give up their 4x discount, and those intentionally polluting the UTXO set won’t stop because OP_RETURN. That is the entire goal. UTXO set pollution.

Higher but reasonable limits allow developers to put data that is actually useful such as Silent Payments in future protocols, and incentivize small data storage (small OPRET < small inscription which also takes up more block space) to be efficient when it happens

Unfortunately there’s a lot of sheep here that follow their favorite flavor of shitfluencer that wants to use them for personal gain.

I’m not educated enough on the issue to comment, but I’ll be following this note in hopes of original ideas. 🤝

https://primal.net/e/nevent1qqsgcp4hfy7rqazwy6jd5k4c6wesw9tcwnzep38kvnahgnzhqrct4hqkj4p0e

A lot of the arguments in favor seem like strawmen to me. "This change will fix this hypothetical problem that isn't actually currently a problem."

Some examples I've read:

Supposedly lightning justice transactions need a more complete picture of the current mempool to work effectively. Justice transactions are exceedingly rare already and pushing false channel states as a way to steal sats is not really a viable method of attack. The only instance I've even heard of a justice transactions happening is when someone set it up themselves just to test it.

Supposedly smaller miners are being left out of getting more high value transactions when people wanting to put out of band data on the chain go directly to the larger miners to get it done. This will lead to more centralization in mining. Are smaller miners really struggling from this? I honestly don't know, but I don't think you can attribute the struggles of small miners to this. Currently the coinbase reward makes up the vast majority of miner income, and every miner that discovers a block gets that regardless of what transactions (if any) are included in the block.

Supposedly since anyone can put unlimited data on the chain anyway we should open up OP_RETURN to make it easier. Seems backwards. Storing excessive non-monetary data on the chain was not part of the design of Bitcoin originally. From what I understand this ability was introduced with SegWit and it seems like an unintended consequence, not a feature.

I also don't understand why there is urgency to push this change through when none of the arguments really apply to the current state of Bitcoin, only future potential problems. It makes me think there are special interests that want this done so they can benefit now and to hell with the consequences. It's either that or hubris from my perspective. Bitcoin, imo, should not be a sandbox for developers to play in and make significant changes like this. It's far too important to humanity.

This whole episode has really shaken my understanding and faith in Bitcoin. It is perhaps not the perfect money that I believed it to be if it is subject to changes like this by a small group of devs. However I still believe that the monetary use of a perfectly scarce asset will outcompete any other uses of the limited block space. I just don't think we should invite those other uses to test it.

There should be no op_return limit in the mempool policy. I want my node to accurately predict what the next block will look like (for better fee estimation). If spammers are forced to rely on out of band solutions to get their transactions to miners they won't show up on my nide until they are mined and in a block.

This could also cause centralisation in mining because big miners like Marathon can gain an advantage by providing services like slipstream.

In the end it doesn't really matter what core and knots do, you can just run libre relay and propegate non standard transactions that way. (As long as enough people use it.)

Sidenote.

We need more knots contributors.

I am now on the fence, coming from the NACK/don’t update camp.

The technical discussion around maximizing OP_RETURN by default is pretty firmly settled. The current default only obfuscates the reality of the mempool. It also creates a de facto centralizing pressure for mining by offering large miners extra fees with little-to-no risk associated because they can expect to confirm the transaction quickly.

However, I am on the fence. The PR was opened and explicitly mentioned Citrea research. I don’t agree with interventionist updates made in preference to any particular product or group or individual.

The governance issues surrounding Core’s approach to the GitHub discussion and their messaging outside of GitHub is extremely concerning to me as well. They clearly do not think there is a consensus mechanism that needs to be honored when it comes to non-consensus implementation changes. And that may be fine but acting elitist about it and signaling that “the plebs don’t know better” is not the move.

Finally there’s the economic and resource consumption arguments, which I haven’t really formed an opinion on.

Economically I don’t believe there is any real longstanding demand for nonstandard transactions. But whether the present demand considerably influences mining centralization? Idk.

Resource consumption: if opening the OP_RETURN door we would surely introduce new users of OP_RETURN. This is Jevons Paradox and it is a reality. But does it outweigh the technical reality explained above? Idk.

That’s all I’ve got for now.

There’s no global mempool policy- Core is just the current dominant implementation.

To answer the question directly though:

I’d be more open to it changing if they put in a witness data limit too. Prunable arbitrary data is better than UTXO bloat. But none of these assholes have the balls to propose a reasonable witness data limit so in the meantime gonna run Knots.