MIME-Version: 1.0
In-Reply-To: <201511142127.53255.luke@dashjr.org>
References: <201511132228.47815.luke@dashjr.org>
	<201511142111.24046.luke@dashjr.org>
	<CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
	<201511142127.53255.luke@dashjr.org>
Date: Sun, 15 Nov 2015 13:16:56 +0100
Message-ID: <CABm2gDryvFsnnV=8Bwc8mQX4JtU9_PgJ0EBhcYjpcSdXjV2_WA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	John Sacco <johnsock@gmail.com>
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving
 with max block size of 32M
Precedence: list

On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Saturday, November 14, 2015 10:52:12 AM Jorge Tim=C3=B3n via bitcoin-d=
ev wrote:
>> Currently bip99 recommends 95% miner upgrade confirmation with version b=
its
>> (bip9) for uncontroversial hardforks just like it does for uncontroversi=
al
>> softforks. It is true that in the case of hardforks miners don't decide =
and
>> it's the whole economy who has to upgrade before activation, but "the wh=
ole
>> economy" and "all users" includes miners, so why not use the only upgrad=
e
>> confirmation mechanism that we have available?
>
> Actually, the economy does not necessarily include miners, and in fact th=
e
> present miner community for the most part does not overlap significantly =
with
> economic activity.

Maybe we should define "the bitcoin economy" is first. In my
definition, miners are definitely part of the economy (and also users
of the system).

On Sat, Nov 14, 2015 at 10:27 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote:
>> "the economy does not necessarily include miners"
>> so the money supply isn't part of the economy?
>
> Not in the context of economic majority deciding hardforks. After all, th=
e
> outcome of the hardfork *determines* the money supply. So the former mone=
y
> supply not supporting the change would just mean they cease to be involve=
d in
> that capacity. But even aside from that, the more relevant factor in term=
s of
> economic involvement is /acceptance/ of bitcoins as payment for real good=
s.

Miners accept bitcoins as payment for a real service (with real costs
like electricity) to the network: extending the longest valid chain
with their proof of work.
In the context of BIP99, there's no concept of "an economic majority"
deciding hardforks. Hardforks are either uncontroversial, in which
case BIP99 recommends 95% miner upgrade confirmation in addition to a
time threshold, or are schism hardforks (for example, an anti-miner
hardfork), in which case BIP99 recommends using a time threshold
alone. But no majority can force the dissenting users to use one
validation rule set or the other: users will always be free to run
whatever free software they like.

> And at the same time, miners also have a tendency to
> upgrade at a different rate than the economy.

That alone seems like a very good reason in favor to confirm that
miners have upgraded in addition to a minimal activation block median
time, not a reason against it

> It might make sense to
> incorporate a miner-trigger, but *only if* the flag is enabled in nodes b=
y an
> option disabled by default, and the BIP clearly specifies that miners mus=
t not
> enable it until they perceive complete economic adoption of the change.

I'm not sure I understand this. The trigger mechanism must be uniform
for each rule change, it cannot be optionally different or consensus
can fail.
How are miners supposed to "perceive" adoption?
The time threshold must be set enough in the future to give users time
to upgrade. But we can perceive miners' adoption, so if the system
knows they haven't upgraded, it should wait for them to upgrade (it
would be nice to have an equivalent mechanism to wait for the rest of
the users, but unfortunately there's none).
Please, remember that this is in the context of uncontroversial
hardforks for which all users (including all miners) are expected to
upgrade to.
To reiterate, schism hardforks are treated differently and the miner
upgrade confirmation becomes completely irrelevant.