public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Mon, 17 Aug 2015 14:15:54 +0100	[thread overview]
Message-ID: <CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com> (raw)
In-Reply-To: <55946E68.5070805@riseup.net>

[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5035 bytes --]

  reply	other threads:[~2015-08-17 13:15 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-22 18:18 [bitcoin-dev] Draft BIP : fixed-schedule block size increase Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46   ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28   ` Tier Nolan
2015-06-22 19:54     ` Gavin Andresen
2015-06-22 20:12       ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23  7:35   ` Ross Nicoll
2015-08-17 15:58     ` Jorge Timón
2015-06-23 19:16   ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46   ` Gavin Andresen
2015-06-22 20:51     ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12   ` Gavin Andresen
2015-06-23 20:26     ` Pieter Wuille
2015-06-23 20:50       ` Peter Todd
2015-06-24  6:14         ` grarpamp
2015-06-23 20:46     ` Peter Todd
2015-06-23 21:24       ` Gavin Andresen
2015-06-26 19:08         ` Peter Todd
2015-06-26 22:01           ` Ivan Brightly
2015-06-26 19:25         ` Peter Todd
2015-06-26 22:16           ` Simon Liu
2015-06-27  2:14             ` Milly Bitcoin
2015-06-23 20:55     ` Roy Badami
2015-06-24  1:43 ` odinn
2015-06-24  3:05   ` William Madden
2015-06-24  3:49     ` Jeff Garzik
2015-06-24 13:06       ` Will
2015-06-24 13:44         ` Gavin Andresen
2015-06-25  0:32           ` Pindar Wong
2015-06-25 13:50       ` Gareth Williams
2015-06-25 14:07         ` Adam Back
2015-06-26 13:47           ` Tier Nolan
2015-06-26 15:13             ` Will
2015-06-26 17:39               ` Gavin Andresen
2015-06-26 19:07                 ` Will
2015-07-01 22:49             ` odinn
2015-08-17 13:15               ` Tier Nolan [this message]
2015-08-17 13:18                 ` Clément Elbaz
2015-08-19  3:45                 ` odinn
2015-08-17 16:11             ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto
2015-06-22 19:32 Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04   ` Stephen Morse
2015-06-22 21:32     ` Ross Nicoll
2015-08-17 15:54       ` Jorge Timón
2015-06-22 21:21   ` Gavin Andresen
2015-06-22 21:39     ` Patrick Strateman
2015-06-22 21:48     ` Tier Nolan
2015-06-23  7:59 Ross Nicoll
2015-06-24  4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24   ` Roy Badami
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox