I think that overstep was more than an overstep and they also neglected mainenance, like fixing the inscriptions hack. Without accusing anyone of anything, I can't help but notice that both the actions and inactions all pointed in the same direction of allowing shitcoinery on the network. Bitcoin is money. Anything that can be done to tighten parameters to shut down non-monetary uses that crop up or sneak in a unintended consequences of other changes, without breaking existing monetary uses, should be done because that is responsible maintenance. It narrows the state space, reduces the attack surface and supports keeping the network distributed by keeping the block light. From a purely technical perspective (I've got no tribal dog here, and my local community if very core-centric, and I am friends with core devs) 110 really looks like a maintenance catch-up after some neglect. Don't shoot but that's my honest read on the technical picture and somebody who has built and maintained software-based systems for a very long time. Instead of fighting about this we could be focusing on making sure that 110 is a technically correct tightening of the bolts. No reason it should be anything else. If there are specific, concrete issues, I am sure they can be fixed if brought to light.

Core overstepped by loosening default relay policy amid disagreement and this proved the concensus rules need to change to overcome the vulnerability of the core team being socially attacked

Pedophiles already exist therefore Bitcoin should accomadate them? That's really your argument? Lopp already put dickbutt pictures on the time chain so now everyone should be allowed to upload baby rape videos?

I've yet to hear anyone say what would be negative about bip110 if it was widely accepted (which I realize is not the case yet). Shouldn't we be asking core to implement it as well? Why don't they?

Ideally they would. Easy for me to say coming in and Monday morning quarterbacking, but it seems like this whole situation is wildly political for no reason. The conversation would ideally have been: "Hey, we're behind on some maintenance. Let's drop some cruft, tighten some unnecessarily loose data limits that are feeding non-monetary use and kill the inscriptions hack." Then we would have a calmly go through back testing against the chain to make sure we didn't chop any legit monetary use and roll the thing. It's not that hard. And then I assume there would be hot cocoa with marshmallows. ☕ Obviously that ignores that there are incentives, financial interests, rivalries, reputations, egos and tribes. I'm not surprised this is hard for non-technical reasons. My point is just how purely non-technical problem actually is here. The actual technical problem itself could have been solved by small number of people in a matter of weeks if they were working together well. Instead we have a total shitstorm. Whatever. It will be fine, but I have to be pro 110 on the merits until someone can explain why its a bad idea from on the merits. 🍿

Why not roll back the change? I’m convinced some people would pause and reconsider how urgent this fork really is. If the goal is truly to minimize damage, reduce division, and lower the risk of a chain split, then reverse the change…

What’s the issue with tighter rules? Isn’t the fact that degens like Todd run Librerelay, that consensus tightening is better suited than policy changes to face/reduce spam? If >40% of network TXs is (potentially horrific-) crap, we should care shouldn’t we?!🤔

When you increase a policy parameter 1200× that’s enforced by default on 95%+ of nodes, that’s a de facto consensus change. It’s embarrassing that an OG like you doesn’t grasp that.

Agreed - Core definitely overstepped with that massive controversial reckless loosening. As a long-term software engineer and manager of software engineering teams, I would have fired them all for that lack of understanding of the unintended consequences and deliberate side-stepping of controls by loosening so much because they don’t want to go back to the community for future loosening. What in your opinion is the “fix” because what I’ve heard from you so far is to run Core v29 and not upgrade, but that’s not really a “fix” to the problem that a very very small number of Core developers made a massive unnecessary high risk change to the default node implementation that a lot of people brainlessly upgrade to. Having lots of nodes switch to Knots is not ideal either because that’s a different concentration risk. Is OpenSats actively funding some other (non-Core) implementations to mitigate this obvious risk to Bitcoin?

No it is not, consensus rules can only be changed via a fork: a soft fork if you tighten the rules, and a hard fork if you loosen them. Relay rules can be equal or tighter than consensus rules, but never looser. The consensus rule for OP_RETURN size is that there's no limit. What Core is trying to do is make relay rules equal to the consensus rules (instead of tighter) Why is this important? When you have tighter relay rules, you create incentives for miners and pools to create an API where one can broadcast non standard transactions (which already happened) which increases the risk of mining centralization. If I want to broadcast a non standard transaction, I just need to contact a handful of these APIs and send my transaction. This makes a handful of big hashing power players to have a different mempool from the rest of the miners, a form of centralization, which creates opportunities for MEV and censorship. And if you have censorship, it's not Bitcoin anymore. So, you're worried with what people can put on the machine, while Core is worried with keeping the machine running. Sorry to say, but in this specific case, Core worries are more important than yours: it doesn't matter what people put in the machine if the machine is not working.

I see just about 15% here. And I'm quite certain that the two thirds of nodes we don't see because they're in TOR, don't look decisively different.