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 76198305 for ; 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 ; Mon, 17 Aug 2015 13:18:48 +0000 (UTC) Received: by ykdt205 with SMTP id t205so125815805ykd.1 for ; 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: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> <55946E68.5070805@riseup.net> In-Reply-To: From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= Date: Mon, 17 Aug 2015 13:18:38 +0000 Message-ID: To: Tier Nolan 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 > > > 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
The "only bigblock" patch you want is actually a= vailable here :=C2=A0https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks=

Le=C2=A0lun. 17 a= o=C3=BBt 2015 =C3=A0=C2=A015:16, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> a =C3=A9crit=C2=A0:
One of the comments made by the mini= ng pools is that they won't run XT because it is "experimental&quo= t;.

Has there been any consideration to making available a ver= sion of XT with only the blocksize changes?

The least "ex= perimental" version would be one that makes the absolute minimum chang= es to core.

The MAX_BLOCK_SIZE parameter could be o= verwritten whenever the longest tip changes.=C2=A0 This saves creating a ne= w function.

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).

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.

On Wed, J= ul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup.n= et> 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.=C2=A0 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 w= ork 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.=C2=A0 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.=C2=A0 If they give notice and<= br> > enough users update, then miners would have to accept it.
>
> The block size becomes min(miner's vote, core devs).=C2=A0 Even if= 4
> years notice is given, blocks would only be 4X optimal.
>
>
> _______________________________________________ bitcoin-d= ev 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"
h= ttps://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/mail= man/listinfo/bitcoin-dev
--001a114d90be4c3895051d81a4a3--