Yeah I unfortunately agree that 100kb OP_RETURN was not needed at all, I think everyone was going to be comfortable with limits up even maybe 250 bytes, enough to use Bitcoin as a data availability layer for rollups.
For my part I'm not updating past Core 29.0, Knots is great to have as it shows that the community is all but complacent
Why do you think its "unfortunate" to disagree with Core?
We verity, we don't trust.
The unfortunate thing is that you are trying to excuse what Citrea is doing. (Also Citrea needed 160 Bytes but that is irrelevant now, they are malicius compnay trying to turn Bitcoin into Ethereum like shitcoin - their intentions shown in the article and verified by Cardano's Hoskinson)
As you say there are companies that respect the Bitcoin ethos and design their technology to use lets say less than 83 Bytes in OP_RETURN.
Thank you for not running the malicious Core V30.
This is what Bitcoin is and its values are. And not because I have posted it but because majority of Bitcoiners are saying it. Those values have been ATTACKED by Core devs. Core devs CENSORED Bitcoin contributes on Github for mentioning Citrea. Core devs ATTACK Bitcoin Knots node runners. And their lies, their lies about filters ....
I think it's great to disagree with Core. It's unfortunate that they chose to pursue this change because it doesn't seem to be necessary at all and it has caused a lot of chaos within the community, which was frankly the last thing we needed. Nevertheless, Bitcoin is made to survive adversity and it's up to node runners to guarantee its success in the long term.
As for Citrea, I'm not excusing them or anything. I think development on Bitcoin should be permissionless, so let them try build new stuff. They can turn Bitcoin into Ethereum only if the vast majority of users actually think that's valuable and start bridging their sats to their L2. I have no reason to believe this is going to happen.
The other unfortunate thing is that Citrea has developed its protocol in such a way as to require more than 80 bytes of arbitrary data, meaning they are going to publish it on the witness instead of as an OP_RETURN output. Had they been less careless with their technical choices, we would probably not be here. Hence my use of the term "unfortunate".
And here is the key.
Core ALLOWED the spam that currently abuses Bitcoin by not fixing it with Luke's PR. So Citrea abusing Bitcoin is direct effect of malicious Core devs actions.
"The datacarriersize policy option is meant to limit the size of extra data allowed in transactions for relaying and mining. Since the end of 2022, however, attackers have found a way to bypass this limit by obfuscating their spam inside OP_FALSE OP_IF patterns instead of using the standardized OP_RETURN. This remains under active exploitation to a degree very harmful to Bitcoin even today.
A straightforward way to address this is to simply fix the bug (#28408), but that was (inappropriately) closed due to social attacks."
https://github.com/bitcoin/bitcoin/pull/28408
I'm familiar with these points. I am not sure that fixing the current instantiation of inscriptions via OP_FALSE OP_IF checks would be enough though. There are ways ways to embed arbitrary data and it seems to be the only option to remove the possibility entirely is to only allow a set of well known transaction types, much more restrictive than what Core currently categorizes as "standard".
They are already fixed in Bitcoin Knots. And Knots is working fine.
All legitimate transactions and use cases can be tested but as for monetary transactions that transfer value, its all fine.
Restrictions is when someone takes away your options - deprecations first, removal second.
One thing to notice is that Bitcoin Knots gives you the FREEDOM to put whatever value in OP_RETURN you like. Think about that too.
