@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?