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 114D57AA for ; Mon, 17 Aug 2015 13:15:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A1E519A for ; Mon, 17 Aug 2015 13:15:55 +0000 (UTC) Received: by qged69 with SMTP id d69so92659765qge.0 for ; Mon, 17 Aug 2015 06:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=szzxkFaw+WBHrPbx9PxucfoKajvk5+sH86wQht+2Xcc=; b=YEcon77N6vOhCLyf6s3somDat4yCxoZ7L3WlMPA/IIPyn3rxC3oC3PktKAMj81hAJW gCk7dl4b2Q6gDzZAcSzNyq43bSLafWLAMpLmNtiB7t6rTcG5sDVEqVhwxafVodj0v6vr OmKWlm/I6mdlZG2Mny5aDWmvm3ILBXMZGWAc2rGpJNJHmCtbcEJFdIP5bfUsfwKyecwq ZNZWGKv7mXJh6dS50z78ls+ElNBUSg7pIArq55Hz2bKsjaWZLPt/jnQYDEyGSupot+gJ uiXkzOChZh6jFoGgzFBZybOJQJpikrDCOKDPk4crFXks1f3XRSmcyoGvz7yPF69OSccA 7Lpg== MIME-Version: 1.0 X-Received: by 10.140.101.234 with SMTP id u97mr2275460qge.69.1439817354299; Mon, 17 Aug 2015 06:15:54 -0700 (PDT) Received: by 10.140.31.181 with HTTP; Mon, 17 Aug 2015 06:15:54 -0700 (PDT) In-Reply-To: <55946E68.5070805@riseup.net> References: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com> <55946E68.5070805@riseup.net> Date: Mon, 17 Aug 2015 14:15:54 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c1666af1ce80051d81993e X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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:15:56 -0000 --001a11c1666af1ce80051d81993e Content-Type: text/plain; charset=UTF-8 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 tip 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= > =rtTH > -----END PGP SIGNATURE----- > --001a11c1666af1ce80051d81993e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 versi= on of XT with only the blocksize changes?

The least "expe= rimental" version would be one that makes the absolute minimum changes= to core.

The MAX_BLOCK_SIZE parameter could be ove= rwritten whenever the longest tip changes.=C2=A0 This saves creating a new = function.

Without the consensus measuring code, the patch would be e= ven easier.=C2=A0 Satoshi's proposal was just a block height comparison= (a year in advance).

The state storing code is also anot= her complication.=C2=A0 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.=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-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"
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-----

--001a11c1666af1ce80051d81993e--