From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C5AA1ACB for ; Fri, 26 Jun 2015 15:13:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D56219B for ; Fri, 26 Jun 2015 15:13:42 +0000 (UTC) Received: by qkei195 with SMTP id i195so18215224qke.3 for ; Fri, 26 Jun 2015 08:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SlDr08Jnutk3ViquNH4jS3wbktdAQxOz7Uuj43K/qno=; b=Vd2KO0Rz3+pfrf8V9NbD/lyjyR+pjvDVjgLdzn2ovufh8DcGnuD5QRjP5HrAgCfF4N HIq6DFzeltg0IDJwcbes6QGc+X7B4amOAu/14WRCRS6GFoiXiPiwwI1q5ydGAOvdmioG 3gsCckDe66q38+pj0tfEzqmQFp0s4OR8j84bLVoTt9yT9bO05INJeWllayv8mgGMMhhh 6za82xn6uXXb5n3DdB2A7mVPMosffJC36g4G3qJ8npdoKQIXmVI+dZrYgXXK31yP9Id4 36mAGlPIuxivsiCkAwrUT98BXgE1wcvU0PETV8J+ux5PV9GqxysLtARX/1FtxC1st0/e ws4g== X-Gm-Message-State: ALoCoQlDPjK4jOFH2jYfS7msvFC6q8gp4rfI1amKSt/DTTwsODbgWgmDrbv6MXUNhtzkNR9FbyK+ X-Received: by 10.55.24.166 with SMTP id 38mr4891446qky.70.1435331621248; Fri, 26 Jun 2015 08:13:41 -0700 (PDT) Received: from [10.149.72.46] (mobile-107-107-56-238.mycingular.net. [107.107.56.238]) by mx.google.com with ESMTPSA id l33sm6968549qkh.12.2015.06.26.08.13.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jun 2015 08:13:40 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83 Mime-Version: 1.0 (1.0) From: Will X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Fri, 26 Jun 2015 11:13:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <19956282-19CC-4150-8865-F211774AF70E@novauri.com> References: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> To: Tier Nolan X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 15:13:42 -0000 --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 wrote: >=20 >> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back 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
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.

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.  

Make the lazy miners' d= efault choice grow at the hard cap growth rate and you should be ok if you w= ant voting.

On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
On Thu, Jun 25, 2= 015 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.

True.

BIP 100 and 101= could be combined.  Would that increase consensus?

-= Miner vote threshold reached
- Wait notice period or until ea= rliest start time
- Block size default target set to 1 MB
<= /div>
- Soft limit set to 1MB
- Hard limit set to 8MB + do= uble every 2 years
- Miner vote to decide soft limit (lowest s= ize ignoring bottom 20% but 1MB minimum)

Block size update= s could be aligned with the difficulty setting and based on the last 2016 bl= ocks.

Miners could leave the 1MB limit in place initially. = ; The vote is to get the option to increase the block size.

Legacy clients would remain in the network unti= l >80% of miners vote to raise the limit and a miner produces a >1MB b= lock.

If the growth rate over-estimates hardware improveme= nts, the devs could add a limit into the core client.  If they give not= ice and enough users update, then miners would have to accept it.

The block size becomes min(miner's vote, core devs).  Even if 4= years notice is given, blocks would only be 4X optimal.
____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-7E8C982E-7408-4246-A54D-E445006DBD83--