however to stop meme bloat from entering future blocks, doesnt require or cause forks.
it can use the same soft consensus trick(no fork) that allowed the bloat. but in reverse to stop the bloat memes continuing to enter.. while still allowing taproot
a 80byte limit is within range of 4mb limit. thus not a block forking just a tx not entering a block thing. thus no fork
its simply hardening the rules again. (undoing the exploit) to prevent future spam
My understanding is that Devs like to work on code with a degree of "future-proofing" in mind. Your proposal does have a certain degree of finality about it. Imagine if a future developer came up with some novel new method of transaction batching that massively aided with scaling, or some other equally worthwhile proposal, but they needed to use that particular opcode and 85 bytes of data to make it work. All of a sudden, we're looking at a hard fork in order to raise the limit again. It's only reasonable that they explore other options first before potentially painting themselves into a corner like that.
A these should not all be pre-activated to just let anything in.
B each should be default deactivated. and then get activated via node updates when they have a purpose via code/decisions of what they should be used for
where node users have had a choice/opportunity to upgrade to be ready to enforce the rules
i know you dont know what consensus is. but after soo many years,, you should know by now
get it yet
nodes should update to be ready to verify new rules then the rules activate
rather then new crap start and everyone race to catchup try to understand the crap
and yes not all new changes get to just happen .. they require the community to have vetted the code and understand the code to then see it as good/worthy of activating
..
i know you want systems that reduce utility of bitcoin
for years you did not want block space changes that allow more transactions with your fake cries of 4mb bloat is bad"
now you cry that 4mb bloat is good because this bloat also reduces transaction counts
your campaign is all about reducing transaction counts per block no matter the method.
yes i call them campaigns as its obvious you have a particular cause you follow that differs from bitcoins utility
you also campaign for reducing how many full nodes(full verification and archiving) are on th network protecting the network
you also campaign for the less users to pay more..
all of your campaigning defy the natural utility/ethos of bitcoin
you love the idea that nodes dont have to upgrade and that nodes get stripped blocks. or nodes choose to prune whole sections of the blockchain.
you goal is not to evolve bitcoin to be a system that allows more transaction on chain (more p2p digital cash utility)
you want another network to be the p2p digital cash
so there is no point in you playing your silly games of pretending your desires are about aiding bitcoin evolution
what you defend is not bitcoin. but human developers that are sponsored to implement code that sways people into using other networks
you do not idolise utility of the masses. you idolise corporate networks wanting to make profit from users by doing middlemen crap