From: Gavin Andresen <gavinandresen@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Tue, 23 Jun 2015 16:12:17 -0400 [thread overview]
Message-ID: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com> (raw)
In-Reply-To: <20150623192838.GG30235@muck>
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd•org> wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> > ==Rationale==
> >
> > The initial size of 8,000,000 bytes was chosen after testing the current
> > reference implementation code with larger block sizes and receiving
> > feedback from miners stuck behind bandwidth-constrained networks (in
> > particular, Chinese miners behind the Great Firewall of China).
> >
> > The doubling interval was chosen based on long-term growth trends for CPU
> > power, storage, and Internet bandwidth. The 20-year limit was chosen
> > because exponential growth cannot continue forever.
>
> Wladimir noted that 'The original presented intention of block size
> increase was a one-time "scaling" to grant time for more decentralizing
> solutions to develop'
>
> Comments?
>
Consensus is that this process is too painful to go through once a year. I
agree.
If you disagree and would like to see a Blocksize Council meet once a year
to issue a decree on what the maximum block size shall be for the next
year, then propose a process for who gets to sit on the Council and how
their decrees are enforced.....
>
> In particular, if bandwidth scaling doesn't go according to your plan,
> e.g. the exponential exponent is too large, perhaps due to technological
> growth not keeping pace, or the political realities of actual bandwidth
> deployment making theoretical technological growth irrelevant, what
> mechanism will prevent centralization? (if any)
Simulations show that:
Latency/bandwidth matter for miners. Low latency, high bandwidth is
better. However, miners with bad connectivity can simply create smaller
blocks...
... until transaction fees become significant. But by the time that
happens, protocol optimizations of block propagation will make the block
size an insignificant term in the "how profitable is it to mine in THIS
particular place on the Internet / part of the world" equation.
(Reference:
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08224.html
)
So: for the immediate future, there is no problem. And in the long term,
there is no problem.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3460 bytes --]
next prev parent reply other threads:[~2015-06-23 20:12 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 18:18 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 [this message]
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
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='CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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