This is the best most honest argument I’ve seen against BIP110 so far. Kudos for this. I completely agree with this POV. Nevertheless I’m running BIP110 because 3 years of centralised abuse of the protocol is too much and I don’t see any other solution.

This is the best and most honest argument I’ve seen against #BIP110 so far. Kudos for this. I completely agree with this POV. Nevertheless I’m running BIP110 because 3 years of centralised abuse of the protocol is too much and I don’t see any other solution. And I’m done waiting for devs to become responsible again. View quoted note →

Any advice for bitcoiners who aren't happy with core governance or direction? I think a lot of us are unhappy with the current situation and feel that bip110 is drawing a line in the sand in response to core's actions. If not bip110 then what?

100% agreed

Would CTV or drive chains be a soft fork where they narrow the rules? I've only seen preliminary discussions on it because they're both still proposals, so I'm not sure how they will work exactly.

Yes since then, I understood that once again you were right 🤓😀 and this is indeed the decisive argument.

I would agree that the precedent is not optimal. but terrible? that's just one opinion. There are other very bad precedents and factors at play that you are not paying enough attention or considering properly IMO. I think that the precedent of allowing an economically illiterage smug clique of corrupt devs to continue degrading the monetary quality of Bitcoin, not fixing bugs, leaving open attack vectors and exploits, increasing the legal and moral risk, encumbering nodes and endangering node decentralization into the future... those are worse. WAY worse precedents. Each one of those is worse IMO than what you think is a "terrible precedent". The change is good you accept that. And the only possible bad outcomes would be real in extreme scenarios where enough mining pools get misled and stuck in rigid ideological restraints like the ones you so effectively spread. If the support from the broad community in pressuring the pools to signal BIP110 is strong enough ALL the doomsday scenarios go away and we have a clean non disruptive upgrade that would be good for Bitcoin and the world.

You will defend Libre RealyGhey for a minority that forces garbage on to a everyone's nodes via pref peering and OOB direct submission; but then rail against 110 for being a minority that can force a majority to "change consensus". How do you reconcile these 2?

@Giacomo Zucco, I respect your work immensely, but I think you're conflating consensus with policy here. BIP-110 isn't forcing a consensus change on anyone. It restores the `datacarrier` config option that Core deleted from `bitcoin.conf` in v30. It's mempool policy - the same category as the 80-byte limit that existed for 10 years. If restoring a configuration option that node operators previously had is "forcing a majority to change consensus," then what do you call Core v30? Six maintainers with PGP keys merged PR #32406 against 93 NACKs from actual node operators, removed the steering wheel entirely, and muted critics (Luke, BitcoinMechanic) who objected. If that's not a "vocal minority forcing change," what is? The precedent you're worried about already happened - except it was Core capturing the default for Citrea's business model in 52 days, against the explicit will of the economic majority. BIP-110 is the antidote to that precedent. It doesn't mandate anything. It says: run Knots if you want filters, run Core if you want the uncapped default. The only "force" here is Core saying you cannot choose your own policy - and that’s the capture I'm trying to reverse. CTV and Drivechains were consensus changes requiring soft forks. BIP-110 is just giving me back the toggle switch Core took away. How is that the dangerous precedent?

That’s not what bip 110 do : it changes rules at consensus level. knots itself allows you to run relay policy that is stricter (probably possible in core to but default much laxer and completely relaxed for op_return in core30)