Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

From: odinn <odinn.cyberguerrilla@riseup•net>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Wed, 01 Jul 2015 15:49:12 -0700	[thread overview]
Message-ID: <55946E68.5070805@riseup.net> (raw)
In-Reply-To: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>

-----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=
=rtTH
-----END PGP SIGNATURE-----