MIME-Version: 1.0
In-Reply-To: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>
References: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>
Date: Wed, 19 Aug 2015 19:28:38 +0200
Message-ID: <CABm2gDrx3XEJX1WSAeyEpZ=cKb4-UB8tcFTKu8DMccZzfBsqYQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
Precedence: list

On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.

For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).

Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.