Return-Path: <clem.ds@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 76198305 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 13:18:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A4C47190 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 13:18:48 +0000 (UTC) Received: by ykdt205 with SMTP id t205so125815805ykd.1 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 06:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=9AtEgIinq8iLp2b4vYtApc1GVRn9kBEJ0lWsgqOBWX8=; b=yZiw8fBk25wpwCOLYpOT5g5hTG6uXncO5DVp5fiZqcwPX+CQ76tStjrYRjJCuD2QFc Chc+ZDl1O9Fk603Mk8BaYYhbHFMzj5pTVMWDDkJXaz74olBx8mHWyluezmQXeE6UAcgi mEJt5+dwGrGhEfb0J1yy6Yv8Rum50G4MUOGXHiSNzw064ilmKfBJ+Pbp5A/D+mCKekzJ iiht5EWok8hg3fSfKso4gOjri1QklbFbXgz+iOB+hD6KA082EK5G2Ta5WoIB9n/uPbZV 5OZzJeajmGAmBEav8dbv0+I7bnkkFWbMnat6dcOhf9VgmCUo8jXMno6rfv2y/DzT/wAu sS/Q== X-Received: by 10.129.74.135 with SMTP id x129mr1337296ywa.98.1439817527991; Mon, 17 Aug 2015 06:18:47 -0700 (PDT) MIME-Version: 1.0 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> <55946E68.5070805@riseup.net> <CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com> In-Reply-To: <CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com> From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com> Date: Mon, 17 Aug 2015 13:18:38 +0000 Message-ID: <CAP63atYR7RdoAHWycNnx2DN9vuX9bKhDC9bLCMjTs7oFs4_u4A@mail.gmail.com> To: Tier Nolan <tier.nolan@gmail.com> Content-Type: multipart/alternative; boundary=001a114d90be4c3895051d81a4a3 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Mon, 17 Aug 2015 13:18:50 -0000 --001a114d90be4c3895051d81a4a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The "only bigblock" patch you want is actually available here : https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks Le lun. 17 ao=C3=BBt 2015 =C3=A0 15:16, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > One of the comments made by the mining pools is that they won't run XT > because it is "experimental". > > Has there been any consideration to making available a version of XT with > only the blocksize changes? > > The least "experimental" version would be one that makes the absolute > minimum changes to core. > > The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest ti= p > changes. This saves creating a new function. > > Without the consensus measuring code, the patch would be even easier. > Satoshi's proposal was just a block height comparison (a year in advance)= . > > The state storing code is also another complication. If the standard > "counting" upgrade system was used, then no state would need to be stored > in the database. > > On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup.net> > wrote: > >> -----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 <adam@cypherspace.org >> > <mailto: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. >> >> 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=3D >> =3DrtTH >> -----END PGP SIGNATURE----- >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114d90be4c3895051d81a4a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The "only bigblock" patch you want is actually a= vailable here :=C2=A0<a href=3D"https://github.com/bitcoinxt/bitcoinxt/tree= /only-bigblocks">https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks= </a></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 17 a= o=C3=BBt 2015 =C3=A0=C2=A015:16, Tier Nolan via bitcoin-dev <<a href=3D"= mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda= tion.org</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "><div dir=3D"ltr"><div><div><div><div>One of the comments made by the mini= ng pools is that they won't run XT because it is "experimental&quo= t;.<br><br></div>Has there been any consideration to making available a ver= sion of XT with only the blocksize changes?<br><br></div>The least "ex= perimental" version would be one that makes the absolute minimum chang= es to core.<br><br></div></div><div>The MAX_BLOCK_SIZE parameter could be o= verwritten whenever the longest tip changes.=C2=A0 This saves creating a ne= w function.<br><br>Without the consensus measuring code, the patch would be= even easier.=C2=A0 Satoshi's proposal was just a block height comparis= on (a year in advance).<br><br></div><div>The state storing code is also an= other complication.=C2=A0 If the standard "counting" upgrade syst= em was used, then no state would need to be stored in the database.<br></di= v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, J= ul 1, 2015 at 11:49 PM, odinn <span dir=3D"ltr"><<a href=3D"mailto:odinn= .cyberguerrilla@riseup.net" target=3D"_blank">odinn.cyberguerrilla@riseup.n= et</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----BEGIN= PGP SIGNED MESSAGE-----<br> Hash: SHA1<br> <br> </span>(My replies below)<br> <span><br> On 06/26/2015 06:47 AM, Tier Nolan wrote:<br> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <<a href=3D"mailto:adam@= cypherspace.org" target=3D"_blank">adam@cypherspace.org</a><br> </span><span>> <mailto:<a href=3D"mailto:adam@cypherspace.org" target= =3D"_blank">adam@cypherspace.org</a>>> wrote:<br> ><br> > The hard-cap serves the purpose of a safety limit in case our<br> > understanding about the economics, incentives or game-theory is<br> > wrong worst case.<br> ><br> ><br> > True.<br> <br> </span>Yep.<br> <span><br> ><br> > BIP 100 and 101 could be combined.=C2=A0 Would that increase consensus= ?<br> <br> </span>Possibly ~ In my past message(s), I've suggested that Jeff's= BIP 100<br> is a better alternative to Gavin's proposal(s), but that I didn't<b= r> think that this should be taken to mean that I am saying one thing is<br> "superior" to Gavin's work, rather, I emphasized that Gavin w= ork with<br> Jeff and Adam.<br> <br> At least, at this stage the things are in a BIP process.<br> <br> If the BIP 100 and BIP 101 would be combined, what would that look<br> like on paper?<br> <span><br> ><br> > - Miner vote threshold reached - Wait notice period or until<br> > earliest start time - Block size default target set to 1 MB - Soft<br> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -<br> > Miner vote to decide soft limit (lowest size ignoring bottom 20%<br> > but 1MB minimum)<br> ><br> > Block size updates could be aligned with the difficulty setting<br> > and based on the last 2016 blocks.<br> ><br> > Miners could leave the 1MB limit in place initially.=C2=A0 The vote is= <br> > to get the option to increase the block size.<br> ><br> > Legacy clients would remain in the network until >80% of miners<br> > vote to raise the limit and a miner produces a >1MB block.<br> ><br> > If the growth rate over-estimates hardware improvements, the devs<br> > could add a limit into the core client.=C2=A0 If they give notice and<= br> > enough users update, then miners would have to accept it.<br> ><br> > The block size becomes min(miner's vote, core devs).=C2=A0 Even if= 4<br> > years notice is given, blocks would only be 4X optimal.<br> ><br> ><br> </span><span>> _______________________________________________ bitcoin-d= ev mailing<br> > list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= =3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev</a><br> ><br> <br> </span><span>- --<br> <a href=3D"http://abis.io" rel=3D"noreferrer" target=3D"_blank">http://abis= .io</a> ~<br> "a protocol concept to enable decentralization<br> and expansion of a giving economy, and a new social good"<br> <a href=3D"https://keybase.io/odinn" rel=3D"noreferrer" target=3D"_blank">h= ttps://keybase.io/odinn</a><br> -----BEGIN PGP SIGNATURE-----<br> Version: GnuPG v1<br> <br> </span>iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb<br> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC<br> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP<br> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH<br> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ<br> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=3D<br> =3DrtTH<br> -----END PGP SIGNATURE-----<br> </blockquote></div><br></div> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --001a114d90be4c3895051d81a4a3--