Why I don’t support horse-trading compromises for Bitcoin protocol development

• Political compromises have no place in bitcoin protocol development. I have my full faith in the consensus-driven scientific process that’s based on open communications, technical merit and peer review. A top-down imposed agreement based on closed-doors lobbying that overrides the technical community consensus process and the established FOSS practices would severely undermine the value proposition of bitcoin and its long-term viability.
  The companies supporting this effort should get their engineers involved in the technical bitcoin community and help build consensus based on technical merit, not force the issue by political means.
• Bitcoin is dynamically changing and should adapt to the environment and new data. I do not think we should set things in stone like that. Let’s double the block size first (SegWit), analyze the situation, collect more data, then decide how to move on.
• The “compromise agreement” has no technical details. Companies committing to support a proposal whose technical specifics are entirely unknown are, in my view, irresponsible.
• 12 months is way too short of a timescale to develop, test and safely deploy a hardfork. We probably need around 12 months just from the moment binaries are ready until you’re kicked off the network if you haven’t installed them. 12 months in total will be unsafe and will without doubt result in a network split.
• I do not believe that a hard-fork for a simple constant increase is worth it. If we’re going through the logistical challenge of coordinating a safe hardfork, we should have much more upside than just that (fungibility/privacy improvements, structural redesign, fraud proofs, etc). Building community consensus around that would be much easier.
• The compromise between “no unnecessary hardforks” and “let’s do an unnecessary hardfork” isn’t “let’s do an unnecessary hardfork”. This proposal does not address any of the hardfork-related concerns and risks brought up by the technical community.
• I do not think that Bitcoin has anyone in a position to agree to such a compromise to begin with. The decision eventually rests upon the entire community and industry, not to any specific persons at Core or elsewhere. An agreement like that is unenforceable, and I do not think that anyone could honestly commit to it in good faith.
• Allowing political compromises to shape bitcoin protocol development sets a dangerous precedent, constitutes a moral hazard and erodes the established FOSS practices and consensus-driven decision making.

I’ll finish with a quote from “On Consensus and Humming in the IETF”, where the IETF explains why horse-trading compromises has no place in consensus-driven decision making:

Unfortunately, the word “compromise” gets used in two different ways, and though one sort of compromising to come to consensus is good (and important), the other sort of compromising in order to achieve consensus can actually be harmful. As mentioned earlier, engineering always involves balancing tradeoffs, and figuring out whether one engineering decision makes more sense on balance compared to another involves making engineering “compromises”. Those sorts of compromises are among engineering choices, and they are expected and essential.

However, there is another sense of “compromise” that involves compromising between people, not engineering principles. For example, a minority of a group might object to a particular proposal, and even after discussion still think the proposal is deeply problematic, but decide that they don’t have the energy to argue against it and say, “Forget it, do what you want”. That surely can be called a compromise, but a chair might mistakenly take this to mean that they agree, and have therefore come to consensus. But really all that they’ve done is capitulated; they’ve simply given up by trying to appease the others. That’s not coming to consensus; there still exists an outstanding unaddressed objection. Again, if the objection is only that the choice is not ideal but is otherwise acceptable, such a compromise is fine. But conceding when there is a real outstanding technical objection is not coming to consensus.

Even worse is the “horse-trading” sort of compromise: “I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I’ll stop objecting to your proposal and we’ll put them both in.” That again results in an “agreement” of sorts, but instead of just one outstanding unaddressed issue, this sort of compromise results in two, again ignoring them for the sake of expedience.

These sorts of “capitulation” or “horse-trading” compromises have no place in consensus decision making.