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 766648B4 for ; Wed, 1 Jul 2015 22:49:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C23F6229 for ; Wed, 1 Jul 2015 22:49:13 +0000 (UTC) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 5394441FD9; Wed, 1 Jul 2015 22:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1435790953; bh=Lvgnl7YnzCiMeypv9PrDp37+BUMHa32Ex1bl0dPJQ0A=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=S1ziuj+BdVc8ly9Hv+jGSIabaFCvl30+oDzBwJrRFfigoQiBwVj8XuV1vmTwDPDbC O9C/h4p/ggK5lOSDFWswSvjR63OU+fkWTPTrNPOd30rmT/O/bJXNuggHNq63HVawxK qipZ9KyR9oxk5QhHCENLy4ZJdA4GZn8QsLlzpcOo= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 04230400E2 Message-ID: <55946E68.5070805@riseup.net> Date: Wed, 01 Jul 2015 15:49:12 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tier Nolan References: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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: Wed, 01 Jul 2015 22:49:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (My replies below) On 06/26/2015 06:47 AM, Tier Nolan wrote: > 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. > > > True. Yep. > > BIP 100 and 101 could be combined. Would that increase consensus? Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is "superior" to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam. At least, at this stage the things are in a BIP process. If the BIP 100 and BIP 101 would be combined, what would that look like on paper? > > - 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) > > Block size updates could be aligned with the difficulty setting > and based on the last 2016 blocks. > > 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 until >80% of miners > vote to raise the limit and a miner produces a >1MB block. > > If the growth rate over-estimates hardware improvements, the devs > could add a limit into the core client. If they give notice 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 bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= =rtTH -----END PGP SIGNATURE-----