Exactly. This change is a policy-level modification, not a consensus rule
Discussion
Right, so changing it on a knots node wonβt do anything
Then why are you complaining? π
because i am here to defend bitcoin core when noone else will. Because i care about the truth and to fight against the lies against us.
You are fighting the wrong fight. People want choices not dictates. There is no good reason to have unlimited OP_Return. The only people benefiting from this are the miners and NO, just because there are already workarounds doesnβt justify removing it. A lot of people donβt want more spam and CSAM.
Just give them an option to keep the limit in the next release, then everyone would be happy. If not, people will just fork off or remove that code and rebuild it anyways.
We already have unlimited op_return, in core and knots.
I donβt see relay policy as effective given new relay networks that will inevitably spring up to get around censorship of economically motivated transactions. Not even talking about core. Core just aligns with this reality.
Itβs really on the miners to stop hurting the network by accepting this type of data.
Youβre right that there is technically no stopping it with relay policy, but relay policy did reduce it and set a standard for transactions over the history of Bitcoin.
I could easily see someone fork off by changing Bitcoin so that blocks with OP Return data over 80 bytes are invalid. I think that attempt will fail, even though I wish it would succeed.
I may be a rare bitcoin user/dev but i have always been very anti filters since the very beginning , so i may have a different perspective than most core devs who are pro filters (standardness), let alone knots people who are even more pro filters (standardness+++)
Do you think that using Bitcoin for non-monetary data storage hurts the monetary network?
I think its a good way for idiot to burn and donate their bitcoin to miners
I would agree with this except that there is data which is considered illegal in most countries with can pollute the chain. What harm would be done by having a hardcoded limit on OP Return?
You didn't answer the question. Answer nostr:nprofile1qqstjdsvmqytynktl5p4wheavda3uck2nl4yzkkx0dk9ky00zheg6pspzamhxue69uhky6t5vdhkjmn9wgh8xmmrd9skctcpzemhxue69uhk2er9dchxummnw3ezumrpdejz78u7ddf question!
I think it temporarily makes onchain txs harder, but that is why we need more people using lightning channels because in a healthy fee market this is inevitable anyways
I know that. I just want the option to not relaying anything bigger than 80 bytes. Why is that so hard to comprehend?
Core doesnβt remove this option
Its deprecated for a good reason though: the option doesnβt have any effect on your node from receiving that data, it just makes your node run less efficiently. Your node will get this data regardless. What youβre saying is you want an option for virtue signalling rather than for any real reason
This is exactly the arguments from the miners. You want to make it easier for them. I donβt. I want to make it harder it is for these junks to propagate and hopefully will deincentivize miners to mine them.
At the end of the day, you canβt tell people what to run. They will switch to knots, stay at 29 or just fork off. What will that achieve for core?
If core makes it harder then people will build around it. Core is just accepting economic reality while knots want: to try to censor and control something they really have no control over. Its communism.
Removing 80-byte OP_RETURN limit doesnβt automatically make Bitcoinβs network more efficient β in fact, it could make it less efficient by introducing bloat and weaken decentralization.
This will lead to higher costs for running full nodes and eventually to centralizations of both miners and nodes. They will be controlled by a few big entities. If that happens, Bitcoin failed.
Is that what you want?
Emdash, you literally just made an ai response? Come on bruh
You said removing OP_return limit will stop people from using SegWit or MultiSig, but it wonβt. That option is still available.
All you do is make every block bigger with NFT and junk. It is good for miners, they make the fees, but what does it do for node runners? They get nothing out of this.
If it will be more expensive or even illegal to store some of this junk. Why would anyone do it?
This will lead to fewer and fewer nodes.
You have to know this could happen. If you donβt then there is nothing anyone else can say. We just have to wait and see how many people actually upgrade to 30. Bruh.
Defender of core, what is the benefit for Bitcoin or people running the software with core 30?
A mempool that better reflects what miners are actually mining? Better fee estimation? More efficient bandwidth usage? Latest bitcoin core features like bitcoin-node and multiprocess (although not sure how much of that is landing in v30). I havenβt looked at the full changelog yet
Not worth it for me compared to hosting and distributing cp and shady vc smart contract projects on my harware, and the attack vectors that come with it for Bitcoin overall, imo. But sure, you do you.
You will do this regardless on a knots node, just the same as a core node
I hate this argument so much.
It's core 30 that makes this easier.
And then you guys say "ya but you will have this regardless because we do it lol"
I will filter shit out as much as I can. I will not morally support this whatsoever.
it doesnβt make it easier, it just changes core to reflect reality. People making these kinds of custom transactions are not relaying via core. I donβt see why doing it with bitcoin-cli is any easier than a web form submission.
Most people building protocols that depend on this would not be using core relay anyways, they would just go around it
Op_return limit from 80bytes to 100kb doesn't make it easier? Why do it at all?
You're not filtering jack unless you implement and enforce stricter consensus rules. Your Knots node will store and serve data you detest once it gets confirmed in a block.
So, you are saying Bitcoin is captured and states can go after node runners for hosting and distributing cp they never wanted because we have no tools to filter this stuff out, no matter which distribution we run? Hey hey congrats on that.
If you wish to make such assertions, I suggest you get an actual practicing attorney to publish an opinion to that effect. Good luck!
The state can make up whatever excuse they want to go after node runners, they can even just say there's cp despite being none. That's a very weak attack vector though, there are far greater threats.
My mempool is my responsibility. Confirmed transactions are the miner's responsability. I can't be held responsible for other people's actions, but that doesn't mean I shouldn't act morally.
Also, confirmed and unconfirmed transactions are completely different.
"Interesting perspective! Itβs true that we all have our roles in this ecosystem. Balancing responsibility and morality can be tricky, but itβs great to see thoughtful discussions around it. Every transaction tells a story! πβ¨ #BlockchainEthics"
Feel free to employ whatever pretzel logic helps you cope better π€·πΌββοΈ
Knots leaves it where it is...