The problem with saying one side is co-opted is that the other side could be, too, and neither is verifiable.
Discussion
Easy, who is making contetiious changes that the majority of the node runners rejects? That is your answer. Bitcoin is a protocol, not a playground. Wake up!
Tbh, the knots side looks more sus, and I was initially very pro-knots. I don't care about forks - we should do it more, not less. The case for core30 is that these larger op_returns are prunable. If I can prune nonmonetary data and run a node cheaply, then I have no reason to care if its expensive to run full nodes. Anyways, everyone is fighting the wrong battle. Segwit was dumb. 4mb is a large block. Fix **_that_**
well, i would, except at this point nobody wants me to do that. but i could throw that out in a matter of a month or two. a solid fork, well designed, a proof of work that isn't vulnerable to scale. i even have ideas about how it would look, put together a plan.
but unless i can pay my bills while i move forward, i can't move forward. so i'm putting that aside. i think there is deeper layers to the protocol that need to be fixed before we move on to matters like segwit and taproot.
Even while prunable, they have to be processed in the mempool and in the initial blockchain sync, which can be a huge bottleneck for people with less computer resources. I agree with you on the segwit 4mb blocks, it’s too big. Just some MBs can make a bitcoin node too expensive to run in places where it’s needed the most, just like arbitrary data can use memory and cpu power that is wasted, knowing it could have been used for monetary transactions, even if ignored after. If it can be pruned, it could not be put there in the first place.