From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-dev@lists.linuxfoundation.org,
	Mark Friedenbach <mark@friedenbach.org>, Chris Pacia <ctpacia@gmail.com>
Date: Fri, 28 Aug 2015 19:42:03 -0400
Message-ID: <12011991.1tUHVb58Dn@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; )
In-Reply-To: <CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
	<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
	<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@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

But that's not what this proposal does. They have to pay the difficulty=
 penalty merely for a *chance* at later being able to mine larger block=
s.

Maybe this could be fixed by allowing miners to produce a larger-than-l=
imit block *immediately* by paying a difficulty penalty. Then we can si=
mply take the 80th-percentile block size in each 2016-block period as t=
he nominal block-size limit in the next period.


On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev=
 wrote:
> It is in their individual interests when the larger block that is all=
owed
> for them grants them more fees.
>=20
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> > When discussing this with Matt Whitlock earlier we basically conclu=
ded the
> > block size will never increase under this proposal do to a collecti=
ve
> > action problem. If a miner votes for an increase and nobody else do=
es, the
> > blocksize will not increase yet he will still have to pay the diffi=
culty
> > penalty.
> >
> > It may be in everyone's collective interest to raise the block size=
 but
> > not their individual interest.
> > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> With this proposal, how much would it cost a miner to include an '=
extra'
> >> 500-byte transaction if the average block size is 900K and it cost=
s the
> >> miner 20BTC in electricity/capital/etc to mine a block?
> >>
> >> If my understanding of the proposal is correct, it is:
> >>
> >> 500/900000 * 20 =3D 0.11111 BTC
> >>
> >> ... Or $2.50 at today's exchange rate.
> >>
> >> That seems excessive.
> >>
> >> --
> >> Gavin Andresen
> >>
> >>
> >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> > 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 blindly
> >> 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 mine=
rs who vote to
> >> raise the block-size limit.
> >> > =E2=80=A2 It avoids incentivizing miners to vote to lower the bl=
ock-size limit.
> >> >
> >> > However, this proposal currently fails to answer a very importan=
t
> >> question:
> >> >
> >> > =E2=80=A2 What is the mechanism for activation of the new consen=
sus rule? It is
> >> when a certain percentage of the blocks mined in a 2016-block reta=
rgeting
> >> period contain valid block-size votes?
> >> >
> >> >
> >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.media=
wiki
> >> >
> >> >
> >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev=
 wrote:
> >> >> Pull request: https://github.com/bitcoin/bips/pull/187
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >