Quote from: dmatthewstewart on May 10, 2025, 06:39:03 PM

But in order for the ones that want to store a lot of info (I consider it spam), they are asking to use my computer to store their information/spam. Nowhere in any instance in society is there a requirement that others may use or abuse your property or use it for reasons you do not want it used.

But, again, you are okay with spam stuffed into fake public keys, like Stampchain? There is no -datacarriersize setting, not even in Knots, that can stop this kind of spam.

I repeat: the removal of OP_RETURN limit does not add additional space for spam. It only offers a significantly less ressource-hungry alternative to store data. If you run a full node, you should love people shifting from fake public keys to OP_RETURN, because you don't need to store the data in the UTXO set and can ignore it.

I really recommend everybody to read the discussion on the developer mailing list, where real technical arguments for and against the change can be found, because I think many of those opposing that change (or any change in policy), are misunderstanding something in that debate. Yes, there are arguments against it too, but imo they're weaker than the arguments in favour.

The most important thing is that there are no additional incentives for spam due to this proposed measure. In other words, spam does not become cheaper.

Quote from: tvbcof on Today at 07:49:10 AM

As I understand things, this change would more formally open the door for single-transaction blocks. (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.) Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?

No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.