Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Gregory Maxwell <gmaxwell@gmail.com>]

On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1) ignores him, which is against the established criteria that all technical
> objections coming from anyone must be addressed until that person agrees, so
> that a change can be uncontroversial. If the group moves forward with the
> change, then the "uncontroversial" criteria is violated and then credibility
> is lost. So a new governance model would be required for which the change is
> within the established rules.
>
> 2) respond to his technical objections one after the other, on never ending
> threads, bringing the project to a standstill.

I don't agree-- I think you've made the mistake of just accepting the
particular framing that Mike has provide; one that (no shock) only
supports his conclusions.

I am aware of no instance where an active contributor to core has made
the claim that no change to consensus can happen without 100% support
(and doubly so, 100% including people who are expressly trying to
disrupt the project by posing opposition which, as you note, is
largely unrelated to the merits of the proposals). Mike has lead you
to believe people have claimed this, but no one has-- it's a view
which is simple, clear, and completely not reflecting reality. Don't
fall for strawman arguments.

In this situation it is also a particularly strong apples/oranges comparison:

Soft forks can happen at any time at the whim of miners-- no
technology which we are aware of (beyond the technology of
centralization) is able to prevent them-- they are not necessarily
even detectable; on this basis they are categorically different than
hard forks.

Moreover, the space of soft-forks the contributors to Bitcoin Core
would ever consider is a tiny space of all possible soft-forks, and
are ones which cannot be rationally understood to meaningfully
undermine the properties provided by the rules enforced within the
software; again making them different from some other proposals and of
a lesser concern.

Finally, the behavior of the technology arising from the inherent
compatibility, radically lowers (in most of our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization
which is harmful to decentralization promoting software diversity.

As I think I commented in one of my messages-- I respond to the
technical arguments not because I believe they are earnestly
motivated, but because they provide an avenue for learning for myself
and others. Even someone trying to disrupt the process and nothing
else can help us learn by acting as an adversary that causes us to
extend our minds and understanding. The process for CLTV has been
ongoing for something like a year and a half and has little risk of
being substantially disrupted at this point.