MIME-Version: 1.0
In-Reply-To: <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
	<CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
	<0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
Date: Thu, 25 Jun 2015 16:07:59 +0200
Message-ID: <CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Gareth Williams <gacrux@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a
growth limiter as a hard-cap and a mechanism for influencing a dynamic
cap within that envelope.

The hard-cap serves the purpose of a safety limit in case our
understanding about the economics, incentives or game-theory is wrong
worst case.

More comments to follow.

Adam


On 25 June 2015 at 15:50, Gareth Williams <gacrux@gmail.com> wrote:
> On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail.com> wrote:
>>Miners can collude today to lower the block size limit.
>
> Of course they can. What, then, is the need for BIP100's hard-limit votin=
g mechanism?
>
> You only need consensus rules to enforce block size limits if you're enfo=
rcing them _against_ miners. Which may be a perfectly valid thing to do (if=
 your threat model includes, for example, the possibility that large miners=
 deliberately create large blocks to gain an advantage over small miners.) =
But BIP100 doesn't address that anyway.
>
> Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB=
 hard-limit growth curve*, and then encourage miners to enforce a soft limi=
t below that, agreed through a voting mechanism? The later can be implement=
ed at any time without consensus changes -- nobody can prevent miners from =
coordinating the max block size they'll build on anyway.
>
> * but with a safer "supermajority" than 75% please :)
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev