Calling it a standardness rule seems... uncomfortable. It seems too high, in that a standard is something generally reached by consensus. I think it should be referred to as a convention, which denotes both that it is commonly adhered to, but deviation is not a significant issue.
Thanks, you raise a good point here. As so often, the terminology is a bit weird here. We should lean more into using "mempool policy" instead of speaking of (non-)standard transactions.
If the current Core version does not mine transactions with OP_RETURN above 80 bytes, why is it considered a standardness rule instead of a consensus rule? Who or what determines that?
At this point, given the rationale in this discussion, what's stopping miners from giving themselves a higher block reward or whatever? What's the point of nodes verifying blocks if PoW is the only thing that counts?
why is it considered a standardness rule instead of a consensus rule?
Because you can change it and Core doesn't reject blocks with large OP_RETURN
Who or what determines that?
Anyone that runs a node. If you change a consensus rule you will fork off (reject blocks or others will reject yours) but if you change a standardness/policy rule, no such thing happens.
what's stopping miners from giving themselves a higher block reward
That is a consensus rule. Your node will reject a block where a miner issues themselves more subsidy due to those rules.
why is it considered a standardness rule instead of a consensus rule?
Standardness rules dictate what txs a node runner thinks should go into blocks (what txs appear in their mempool and what txs they relay to others). Consensus rules dictate what txs are valid when a node finds it in blocks that have been mined by miners.
Standardness rules are kind of like the rules parents might enforce in their households - what's polite and proper - which can vary wildly from house to house. Consensus rules are more like laws that apply no matter which household you're in - no killing, no stealing, etc.
For instance, my standardness rules might say that I not want to store or relay pending txs with OP_RETURN outputs. But, if a miner mines a block that contains txs with OP_RETURN outputs, consensus rules dictate that I accept the block as valid despite them disagreeing with my standardness rules (assuming I don't want to fork from the network).
Basically all this drama is about making standardness rules for OP_RETURN outputs identitcal to consensus rules.
Who or what determines that?
Standarness rules are dictated by the bitcoin node software that you run. Consensus rules are dictated by the network as a whole.
At this point, given the rationale in this discussion, what's stopping miners from giving themselves a higher block reward or whatever?
Consensus rules. The rest of the network will reject those blocks paying higher rewards as invalid.
What's the point of nodes verifying blocks if PoW is the only thing that counts?
PoW isn't the only thing that counts. It's not the only consensus rule.
Basically all this drama is about making standardness rules for OP_RETURN outputs identitcal to consensus rules.
Yes.
So why was the 80-byte OP_RETURN limit never a consensus rule in the first place? I suppose that because Core never made it so.
This is the danger we are facing. That the Core church is getting to define what bitcoin is, because most people just run Core's software and go along with whatever they do. We need competition in churches. It's a shame that in 2017 and later many developers went on to making competing forks that have gone nowhere. I hope they come back to bitcoin and help people understand that bitcoin is not Core.
PoW isn't the only thing that counts. It's not the only consensus rule.
How so? When bitcoin gets widely used, let's say the majority of miners start awarding themselves more bitcoin. They would just need Core to provide a convenient excuse to distract people. After all, with which other coin that nobody uses do you intend to trade?
Some might say: "The people would revolt!" Well, now we have central bankers and their cronies stealing >2% of humanity's output every year (the inflation target, and this doesn't even account for productivity increase due to technological progress), and I don't see anyone revolting (in fact, most people love this system).
Limiting OP_Return outputs would be a soft fork. Also, an utterly pointless soft fork: you can easily bypass any consensus limit we could reasonably come up with, e.g. with unspendable outputs.
The whole point of OP_Return was to encourage people to use a less harmful, prunable, output format rather that growing the UTXO set.
Sorry to sound like an ass, but deciding whether a proposed code change is the right path forward is not a public vote—it’s a technical discussion. You have to make arguments that convince the project contributors to influence the outcome.
As far as I can tell, there is a lot of culturally motivated opposition and some poorly substantiated doom-saying, but I have yet to see a technically convincing argument against this change.
I can understand the argument that this change might reduce the pollution of the UTXO set in favor of OP_RETURN, but completely removing the option for the user to easily configure these mempool policies seems a bit extreme.
Yeah, leaving the configuration option in seems fine. It addresses one of the main reasons for this debate, and it doesn’t hurt anyone but the node operator to use it.
OP_RETURN