MIME-Version: 1.0
In-Reply-To: <2081355.cHxjDEpgpW@crushinator>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
	<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
	<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
	<2081355.cHxjDEpgpW@crushinator>
From: Btc Drak <btcdrak@gmail.com>
Date: Sat, 29 Aug 2015 00:36:20 +0100
Message-ID: <CADJgMzsn_BAynjwFB93DLP9-xSkH4N+5D_O7CH1ajW1PUy-m0Q@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
	(draft)
Precedence: list

On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip@mattwhitlock.name> wro=
te:
> However, this proposal currently fails to answer a very important questio=
n:
>
> =E2=80=A2 What is the mechanism for activation of the new consensus rule?=
 It is when a certain percentage of the blocks mined in a 2016-block retarg=
eting period contain valid block-size votes?

I chose not to address hard fork methodology at this stage because I
wanted to focus on the main algorithm. There are a number of options
open to us for deployment including a simple fixed activation (which I
think is feasible because there is a a lot of awareness and the
industry shows they are willing to rally around a single proposal). If
there are any strong preferences, I can add a deployment section
although I think it's less interesting until we forge a clear way
forward with what blocksize proposal to use.