Users of BitStamps, renewed Counterparty interest, and Runes show that they will do it anyways
Discussion
I'm honestly confused how it didn't create a fork to pay a miner to mine a TX that doesn't follow the existing limit.
That tells me core has already turned against the node runners.
Consensus rules are more relaxed than the "standardness" rules for accepting a TX into mempool in Core and Knots
That doesn't feel like selling the node runners out to the big miners to you? The consensus rules should have been the same as the mempool rules for core.* The only reasons for a difference are a bug, incompetence, or ass kissing big mining firms.
The most overtly node runner hostile part is that they started with an out of band TX to create a demo block. Now node runners can't set a consensus rule smaller than that block without rolling back the chain and forking.
They changed the rules without properly informing the node runners then said we were idiots for wanting our mempool to not match the consensus rules we didn't want that they have now forced on us.
Support the change or not, the people behind it are asshats who are openly hostile to node runners.
*I understand why knots might have different consensus vs mempool rules but this is core we're talking about.
If core had the same mempool rules as consensus rules it would look more like Libre vs Knots. I'm not necessarily opposed to that but would need to fully consider impacts. Decisions were made by Core at the time to have these filters to try to limit some forms of abuse but it has in turn lead to centralization as people find ways to work around the limits while staying in consensus.
They set a mempool limit of 80 but no consensus limit and told everyone the limit was 80.
How is it not malicious to lie to the people who can't read the code and understand it for lack of time or skill.
Now we can never set a consensus limit smaller than their demonstration block without a fork and rollback. They never had the conversation in good faith. Dicks no matter how you feel about the change.
I'm guessing each time it's done there's less impact... And I would bet it keeps trending that way. So no change needed.
Thats where your assumption may be wrong. Anything that promotes going directly to miners, vs being relayable via nodes, is ultimately bad for node operators, decentralization, and layer 2
I'm not worried about going direct to mining pools. I think it's about the utxo set and not even the size but probably the added processing needed to do the IDB and full validation. I was trying to think of the absolute worst case scenario were every single sat is used in its own utxo and inscribed with the max 4mb of garage data. How big would that make the utxo, how long would it take to get there and how long would it take to do a full validation. Then try that scenario with what might actually be possible in reality. Like how bad could it actually get. I didn't really think it through. Full nodes need to be able to do full validation and not rely on shortcuts. So writing all that out it does seem like unlocking op return is good as it would require less processing during full validation. And then if you still see transactions using inscriptions or whatever then you can reason that it's adisguised attack on Bitcoin.
Worst case scenario can be between the extremes of..
Every block is full, equals about 200 GB of data per year. A 2 TB drive will be full within the next 3 or 4 years and then time to upgrade to a 4 or 8TB
Or
No inscriptions, or even op returns... maximum number of utxos.. still between 1mb and 4mb per block, but increasing thousands of utxos per block.. with valid financial dust transaction outputs.
Point is that the utxo problem can occur no matter what, and needs separate disincentive. Eg. No hourly dca as utxos, keep it custodial in lightning or exchange and withdraw as lightning or larger utxo. Educate on common sense utxo sizes or 1,000,000 sets or higher. Samourai support for 100,000 is just as much of an attack as sphinx 100,000 sat channels. Main chain needs to be done with care. Every TX should be 3+ inputs, 2+ outputs