From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-dev@lists.linuxfoundation.org, Btc Drak <btcdrak@gmail.com>
Date: Fri, 28 Aug 2015 17:15:40 -0400
Message-ID: <2081355.cHxjDEpgpW@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; )
In-Reply-To: <CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
	<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
	<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
	(draft)
Precedence: list

This is the best proposal I've seen yet. Allow me to summarize:

=E2=80=A2 It addresses the problem, in Jeff Garzik's BIP 100, of miners=
 selling their block-size votes.
=E2=80=A2 It addresses the problem, in Gavin Andresen's BIP 101, of bli=
ndly trying to predict future market needs versus future technological =
capacities.
=E2=80=A2 It avoids a large step discontinuity in the block-size limit =
by starting with a 1-MB limit.
=E2=80=A2 It throttles changes to =C2=B110% every 2016 blocks.
=E2=80=A2 It imposes a tangible cost (higher difficulty) on miners who =
vote to raise the block-size limit.
=E2=80=A2 It avoids incentivizing miners to vote to lower the block-siz=
e limit.

However, this proposal currently fails to answer a very important quest=
ion:

=E2=80=A2 What is the mechanism for activation of the new consensus rul=
e? It is when a certain percentage of the blocks mined in a 2016-block =
retargeting period contain valid block-size votes?


https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki


On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> Pull request: https://github.com/bitcoin/bips/pull/187