discuss
Discussion
Thanks for the explanation.
We'll find consensus.
(I was working on a tool that makes use of OP_return data , and I'll be happy to release it, in fact it's already working, but adhering to max 60 bits even for tech reasons.(Tagging)
Its good to see the other side of this argument.
As a non technical user by first glance is this article is using a disingenuous framing and weasel words like “ a bunch of trolls did this”
Still undecided because I’m so midcurve iq
Seems both sides use such language to some degree.
I’m of the same status.
tldr segwit opened the door to storing garbage on chain so we may as well remove the op_return constraint too.
give me a break.
Segwit has not opened the door for that. It was always possible by replacing public keys with data in transaction outputs.
A very well written and thought out post that every node runner (and bitcoiner) should read on the OP_RETURN subject.
Compelling arguments on both sides.
As expected, it has very soft language surrounding the financial implications. Arguing "filtering non-standard transactions could be harmful because the nodes are missing out on part of the network"
What part exactly? Spam. Obviously this is up to the code runner to determine. Previously this had been 83 bytes of data. With an unconfigurable, limitless OP_RETURN it is billed as:
Well the attackers are running software that can increase the OP_RETURN anyway so why would we allow you to run software that disallows it on YOUR node?
Utter nonsense.
The next town allows people to spraypaint anyone's house with their messages. So, it's useless to prevent it in our town because they will just go over there and do it.
The point is lost on him that there's a reason different towns have different rules. Each one having their own...wait for it, CONSENSUS!
This blog post is invalid in my mental data set, it doesn't mean it doesn't or won't exist but, I am not storing it in my brain.
Every node has to have the same consensus rules, we are debating policy here, which only effects the mempool and may indeed be different. If the data carrying transaction propagates no matter if it is switched on or not, and the transaction does not incur disproportionate cost to validate and relay, there is little point in not relaying it, since it is latest reveived and processed by the node by the time it is mined.
And as I have stated on many other threads on this topic, a consensus has a definition that I am using. If I meant
As for the cost, yes it does. If the only way to propagate spam was to have a sidechannel to a miner that is socially coslty, technically costly, and still block weight costly.
If every peer you connect to rejects your transactions as invalid by not keeping it in their mempool, that make it a time and opportunity cost as well.
This always smack of the little girl throwing fish back into the ocean that washed ashore. She'll never be able to save them all but that's not the point. The ones she did save are grateful. Never tell anyone that doing what they believe has "little point" because it alone doesn't fix the problem. It is the agregate actions of many that do.
Paying to a fake key or hash cannot be controlled by policy, no matter how aggressive you get. You might say this is expensive, but not by much more than embedding data in fake p2ms (which is controllable by policy). Is there a point to forcing people into the worst class of data embedding in terms of node resource consumption?
Because Bitcoin is not a distributed data storage service. It is a monetary network for monetary transactions. Paying a fake key IS a financial transaction at the end of the day. If I pay a shell company for items that I never receive I still paid it.
Preventing spam is not the point anyway, it is this strange reframing of "We are taking away a config option which gives you more freedom"
This is blatantly false and could only serve to make spam easier to do. That is the contention, nothing else.
I don't care if spam actually increases or decreases. I want people to FREELY choose to enable spam or disable it. Everything else is sophistry.
i fink we shud uus eferium insted
My point is, did anyone asked for this? is this necessary for improving bitcoin or txs?no, its just to have a better way to store random data, so why is Core, that should be very conservative pushing this. The argument of they can already do it in other ways is not a valid argument.
It could dampen future growth of the UTXO set, which I think is very important.
Bitvm might be a net good for some
Knots makes sense because it is user configurable
But we need mysterious 3rd options on node software
Don’t see why you’d call people trolls …
Lost me at code complexity and cognitive load. I mean, look at the settings, cognitive load is already huge whether you remove one option is irrelevant.
Somehow the argument is for fewer options which is bizarre to me considering many people don’t want bitcoin being used as a database for random stuff storage. You’d think people would have more options.
Yes the vast majority does not change defaults BECAUSE we made it so hard to figure out what any of it does. These settings are not designed in user friendly ways.
It’s also bizarre to me that you’d remove a “mild deterrent” to appease an entity doing harm to the network in the first place. 🤷‍♂️
“Hey, you’re hurting me, could you stop punching me in the head and kick my foot instead? It doesn’t hurt as much”
"The local effect of a user setting -datacarrier=0 or -datacarriersize=X on their node would effectively just be shooting themselves in the foot: they would willfully blind themselves to part of unconfirmed transaction activity."
Therefore we must forcefully hold their eyes open like clockwork orange.
Sounds very measured, logical and reasonable to me....
The Horses mouth, Antoine, no ODELL:
"If Bitcoin was so brittle that Core choosing to relay perfectly safe, inexpensive to validate, consensus-valid transactions would break it, it would be utterly uninteresting in the first place!"
Since cars are so brittle that they can be destroyed by pouring sugar into the gas tank, are they utterly uninteresting in the first place?
First they refused to change the filters to address the spam in 2023, and now they want to change bitcoin to remove the reason for filters entirely. If we are going to change bitcoin, change it in a positive way that helps the network remain decentralized. Removing the reason for filters to exist is only going to burden lightweight nodes that depend on these filters to work.
He's right.
Why the urge. No consensus 🤷🏼‍♂️ > Knots
Consensus around what is a valid transaction is not changing. What ultimately is changing whether MEV/MEVil is perpetuated or is decreased. The limit only serves to provide increased centralization pressure and revenue to mines for out of band payments and weakens the public mempool, which is critical to a healthy network.
Maybe. Maybe not.
Elaborate please, happy to hear you out
The argument (if I understand it correctly) is that individual non mining nodes using spam filters will only push miners to link up and pass blocks directly to each other thus diminishing the effect of the mempool THEREFORE core needs to “nudge” non mining away from using these spam filters. (What is spam is in the eye of the beholder, but I digress)
The thought process is that if miners pass along the blocks the menpool will die and the miners somehow own Bitcoin. Maybe.
But maybe not: maybe the. Odds and users of Bitcoin split the network with a softfork or something or maybe something else that I’m too dumb to comprehend happens.
I don’t necessarily accept the consequentialist take that “we must change Bitcoin because (future projected possible bad outcome)”
Apologies for an X link, but this is the most thorough and neutral technical description I have found and recommend everyone to read and consider https://x.com/bitschmidty/status/1918257532415385742
I can definitely understand and respect your take as you are clearly thinking it through so respect there. The one fact I would really push on is, that is only one of several considerations in this change. So even if you are skeptical of that one argument, I’d encourage you to check out Schmidty’s notes on the others 👍🏻
I am trying to bring this discussion down to kind of the simplest points for my simple brain, please check my math. Effectively the argument is remove the op_return limts and even remove the ability for node runners to turn them back on because people are finding ways to add not tx critical data to transactions anyway. Is that it at it's root? By definition, the data that is being added is non-critical to monetary transactions on a network designed to be a monetary network. Do I have this right?
Resistance to change is a feature not a bug.
Do we believe that Citrea bridge tx’s, or Ordinals, or you name it offer legitimate demands for block space?
Do we not believe that within a reasonable timeframe a maximum possible amount of bloat would occur and then the market would eliminate this behavior?
Bitcoin has defense mechanisms other than code changes, even ones that are “valid”. So the question is do we believe they work or not?
Is Bitcoin global money? Then it is NOT a data anchoring system. Even if for now, some people choose to use it as such.
Bitcoin was made for monetary transactions, not random crap data. Stop funding for Bitcoin Core devs, they went rouge.