Maintaining such a patch is probably a couple of days work per year, assuming a worst case scenario of the patch being hard to maintain. Maybe half a day if you can cherry-pick it out of Knots. This is a much lower bar than having to maintain a custom Bitcoin Core fork for consensus changes. Don't be shy.

See also the mailinglist thread, particularly Sipa's comment: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/g9SIY4iqDQAJ

Citrea publishes some whitepaper(!), for a bridge that would benefit from relaxed OP_RETURN limits. Immediately everybody at Core: "yeah let's DROP the limits - they're useless anyway. LFG 🚀" All the while other major changes (e.g. CTV) there's years of filibuster: Where is your signet implementation? Where is your documented user demand? Where is the documented consensus? etc etc etc [Ironically, something like CTV would have done away with the interactive presigning ceremonies that particularly hinder 2way pegs such as said Citrea's bridge] You see the point why people are confused by how Core is handling that, don't you??? Besides, blocking dissenting voices from GH for the slightest of disagreements is absolutely disgusting 👎 This may break the straw for many ppl

Citrea is much further along than a whitepaper. The limits were on the verge of being dropped two years ago because inscriptions made them useless. That change was only held back by the argument that there's a small range of sizes where OP_RETURN is cheaper. That was never a strong argument, so yes, a single example like Citrea was plenty to dismiss that last remaining argument. I explained all that in my mailinglist post, feel free to read it. Consensus changes like CTV is totally different from standardness. The latter requires broad consensus, because the consequence of inconsistent enforcement are catastrophic, etc. Modetating harassers is perfectly legitimate. His concern about a conflict of interest was absolutely spurious here. It's also been stated multiple times that discussions about standardness should be had on the mailinglist, not in the pull request. Pretending to be a censorship victim is the oldest trick in the book.

* The former requires broad consensus

Thank you for the response. Re Citrea. While they might be further along, it's still far from the usual rigid requirement, and certainly not an operational product. This just makes the whole reference to and argument for Citrea in the OP mailing list incredibly weak (and dangerous imho) Re: GitHub First, I disagree that this qualifies already as "harassment". It's a valid, albeit dissenting argument, which should be able to be presented at the main stage. Second, resorting to fine print bureaucract arguments for blocking ("Oh you should not have discussed this here's but in the line over there") makes Core look incredibly weak and insecure. Especially without warning/notice. You must see that. This is not the way trustworthy stewardship of a critical FOSS project looks like. Even benevolent dictators must be benevolent to not lose support from Us the People.

> without warning/notice The whole thread was full of warnings. Warnings don't have to be individually tailored. Moderators are often developers too and have better things to do with their time than to give a non-contributor extreme benefit of doubt. Or even to have rigorous due process. Every second these people have to waste on this nonsense is time they're not fixing the next CVE.

Not sure you guys realize how arrogant, snobbish and elitist this comes across. "Shut up and dribble you plebs! The Pros will handle this. This is Devs-only business!" You *will* the support of the user base, if such important changes are just pushed through by a handful of ppl - while other changes (which you may not like) are filibustered for yearz. And snarly sentiment a la "Good luck with your fork" just confirms this. Disappointing.

Are you aware that you *could* in fact become one of this handful of ppl, or not?

Wut? No, you can't just become a Core maintainer on your own. You first need permissions of others. Even counting as a contributor requires other people to actually have your PR merged

And that is good, lest every bozo starts contributing code that may or may not work, or even wreak havoc. In other words, you need competence. Competence that you don't just attribute yourself with, but that is recognized by a group of people who have been showing high degrees of competence themselves. I.e. core maintainers. And that is exactly the status quo. I don't see what's difficult about this to understand.