Content-Type: multipart/alternative;
	boundary=Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Mime-Version: 1.0 (1.0)
From: Will <will.madden@novauri.com>
In-Reply-To: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
Date: Fri, 26 Jun 2015 11:13:38 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <19956282-19CC-4150-8865-F211774AF70E@novauri.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>
	<CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
	<CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list


--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Make the default soft vote =3D to previous max block size * 1.09 every 12k (=
or whatever mirrors the hard cap growth rate) and don't allow voting to lowe=
r the soft limit and I think you have something.

You need a default that grows because most miners are lazy and will do squir=
relly things like hard code 8000000 as their vote permanently. =20

Make the lazy miners' default choice grow at the hard cap growth rate and yo=
u should be ok if you want voting.

> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
>=20
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
>> 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.
>=20
> True.
>=20
> BIP 100 and 101 could be combined.  Would that increase consensus?
>=20
> - Miner vote threshold reached
> - Wait notice period or until earliest start time
> - Block size default target set to 1 MB
> - Soft limit set to 1MB
> - Hard limit set to 8MB + double every 2 years
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB=
 minimum)
>=20
> Block size updates could be aligned with the difficulty setting and based o=
n the last 2016 blocks.
>=20
> Miners could leave the 1MB limit in place initially.  The vote is to get t=
he option to increase the block size.
>=20
> Legacy clients would remain in the network until >80% of miners vote to ra=
ise the limit and a miner produces a >1MB block.
>=20
> If the growth rate over-estimates hardware improvements, the devs could ad=
d a limit into the core client.  If they give notice and enough users update=
, then miners would have to accept it.
>=20
> The block size becomes min(miner's vote, core devs).  Even if 4 years noti=
ce is given, blocks would only be 4X optimal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Make the default soft vote =3D to prev=
ious max block size * 1.09 every 12k (or whatever mirrors the hard cap growt=
h rate) and don't allow voting to lower the soft limit and I think you have s=
omething.</div><div><br></div><div>You need a default that grows because mos=
t miners are lazy and will do squirrelly things like hard code 8000000 as th=
eir vote permanently. &nbsp;</div><div><br></div><div>Make the lazy miners' d=
efault choice grow at the hard cap growth rate and you should be ok if you w=
ant voting.<br></div><div><br>On Jun 26, 2015, at 9:47 AM, Tier Nolan &lt;<a=
 href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmail.com</a>&gt; wrote:<br=
><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">On Thu, Jun 25, 2=
015 at 3:07 PM, Adam Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cyphe=
rspace.org" target=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote:<br>=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">
The hard-cap serves the purpose of a safety limit in case our<br>
understanding about the economics, incentives or game-theory is wrong<br>
worst case.<br></blockquote><div><br></div><div>True.<br><br>BIP 100 and 101=
 could be combined.&nbsp; Would that increase consensus?<br><br></div><div>-=
 Miner vote threshold reached<br></div><div>- Wait notice period or until ea=
rliest start time<br></div><div>- Block size default target set to 1 MB<br><=
/div><div>- Soft limit set to 1MB<br></div><div>- Hard limit set to 8MB + do=
uble every 2 years<br></div><div>- Miner vote to decide soft limit (lowest s=
ize ignoring bottom 20% but 1MB minimum)<br><br></div><div>Block size update=
s could be aligned with the difficulty setting and based on the last 2016 bl=
ocks.<br></div><br>Miners could leave the 1MB limit in place initially.&nbsp=
; The vote is to get the option to increase the block size.<br></div><div cl=
ass=3D"gmail_quote"><div><br>Legacy clients would remain in the network unti=
l &gt;80% of miners vote to raise the limit and a miner produces a &gt;1MB b=
lock.<br><br></div><div>If the growth rate over-estimates hardware improveme=
nts, the devs could add a limit into the core client.&nbsp; If they give not=
ice and enough users update, then miners would have to accept it.<br><br></d=
iv><div>The block size becomes min(miner's vote, core devs).&nbsp; Even if 4=
 years notice is given, blocks would only be 4X optimal.<br></div></div></di=
v></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83--