Post
Topic
Board Development & Technical Discussion
Merits 4 from 4 users
Re: Removing OP_return limits is a huge mistake
by
gmaxwell
on 02/05/2025, 20:35:24 UTC
⭐ Merited by vapourminer (1) ,JayJuanGee (1) ,PowerGlove (1) ,garlonicon (1)
It was more to question how the other user could so boldly proclaim what Bitcoin's purpose was. When it is impossible to be clear about this position. I didn't know about some of those other satoshi posts, but I cherry picked just one precisely because both positions can be defended and bitcoin's purpose is pretty vague and can't be defined by a individual parties for everyone else.
Because some of us have been here since the start or have studied it enough to know how Bitcoin has been presented and understood.  Perhaps not you, and that's fine-- but other people know things you don't. Smiley  Particularly in this context as both d5000 and I are speaking in favor of *not limiting* and so the reason that we've both pointed out that the purpose of Bitcoin is not as some file storage is to make it clear that supporting removing a limit doesn't mean we think that's a good use of Bitcoin.  We're all aware that there are people who argue otherwise, but we're not actually having a debate on that subject in this context.

Quote
I'm not strongly on any particular side, but this definitely could have been approached quite differently and possibly a better solution could have been provided for the problem that it is intended to solve.
I mean that's kind of a useless comment, no offense intended. If that's your position why post? It's an empty position.  Anything could be done differently, and how can you know that there is a better solution unless you know of one?

Quote
The worst part for me is the removal of the config options, why should I as a user not be allowed to decide the limits for myself?
Stop with the allowed thing.  That is serf thinking.  No one is allowing you or not allowing you to do anything.  There is the fable of an elephant held with a tiny rope. When the elephant was small it couldn't break the rope and then it was conditioned for its whole life to believe the rope held it.  The option in the software is a rope, you think that the choices that it offers you are your constraints. They are not.

If you have some preference for how your nodes behaves, just apply a patch locally. This sort of thing is usually a one or few line change. If you don't know how you can learn or get someone to do it for you.  For things that existed and are removed you can reverse-apply the patch. Or just run a different version (including an old version or someone elses fork), though that's overkill.   If the issue isn't important enough to do that, how can it be important enough for other people to maintain the option?  To carry tests for it, to make sure no further changes interact with it,  to host endless uninformed debates by strangers with opinions about the default value of the setting?  

The purpose of the software is to embody its authors ideas about the best way the software should work in order to form a working, useful, system.  It has options because sometimes people are in different situations and have different needs, and so the best solution for them is different-- for example you might have more or less storage available so you might choose to be pruned or not accept incoming connections.   But in this case if the difference of opinion is about what the system is or is useful for as a whole, or that kind of thing-- rather than a situational difference then the solution is not a different knob.  And you should not be afraid to break the rope, to make a change that isn't in a list offered to you by default. Being able to do that is what makes you free.

The irony though is that I doubt there is all that much care about removing the option, removing it is just the simplest and safest way to deactivate the limit.  For all the sound and fury I can't find a single message to the author of the PR asking him to consider a version that preserves the switch and only changes the default to unlimited.

I highly doubt the author of the PR or the software developers really care much about removing the setting, to all of them the meaningful part of the change is changing the default behavior.   Though after seeing dozens of overwrought posts laboring under the false believe that removing the setting is an impingement on their freedom,  I'm starting to feel in favor of removing the setting.  Telling people the rope doesn't hold them doesn't seem to work for everyone, some won't be free until they break the rope themselves.

Quote
Besides, I don't think this removal will have the intended consequence that the authors believe it will. If I understood correctly, it is supposed to encourage them to use less harmful methods. However, if the other method has a discount on fees then I don't see why they would change anything in the way that they store data? Did I miss something?
Lets imagine that it would not change any of the data-storage peoples conduct.  Then the limitation and the option should still not be there, it is added complexity, risk, limitation without a benefit.  That said, there are people who prefer data to be in outputs, for whatever good or bad reasons and presumably will be others in the future. It's preferable that they have the option of not bloating the utxo set. And when they do and yet choose not to, then it's important that it's clear to everyone that their conduct is intentional and not a result of a limit imposed on them by others.