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 DFCCEAC1 for ; Tue, 23 Jun 2015 20:12:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EDBD1AF for ; Tue, 23 Jun 2015 20:12:19 +0000 (UTC) Received: by lagx9 with SMTP id x9so13640068lag.1 for ; Tue, 23 Jun 2015 13:12:17 -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:to :cc:content-type; bh=3kvh2FnB0znB/RjuiAvJba2UVYx3mNsKRG1aaloS20E=; b=Y8rJG7VJiXPzBDd7IomUmDvtap9VlMXd3bL4RxcH0W4l/00bo6lI5C0WP9w1i20Qe4 ZzK4b4cqDTbdrb0RBlykewL2UiNZ0SkwwAQ+OXOZT24hu2jBQzKZUFTqWt+iKp+CCYx1 WkHTLoQsb3joKYczqB69sKIUW85ApEwHTqARG3/xiO6+rlwr43zddWKaOqJmHMFBlyX3 mqGjiUi5sSDMzFwwJ88jl6pAxIW4vUqaLExuOsZqRuKacUoV7pEq7Yv798QWasTvk8SN b/KZ5ghQUr8lYkUSZxU7e82gr0N+OSpjOq2/7rNr/oG/YGZ85MdpvnOQ20HUlL9b5aMa 2Q+g== MIME-Version: 1.0 X-Received: by 10.112.147.201 with SMTP id tm9mr1565824lbb.40.1435090337603; Tue, 23 Jun 2015 13:12:17 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Tue, 23 Jun 2015 13:12:17 -0700 (PDT) In-Reply-To: <20150623192838.GG30235@muck> References: <20150623192838.GG30235@muck> Date: Tue, 23 Jun 2015 16:12:17 -0400 Message-ID: From: Gavin Andresen To: Peter Todd Content-Type: multipart/alternative; boundary=047d7b34391acb25c705193501cb 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: Tue, 23 Jun 2015 20:12:21 -0000 --047d7b34391acb25c705193501cb Content-Type: text/plain; charset=UTF-8 On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd 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 --047d7b34391acb25c705193501cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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:
> =3D=3DRationale=3D=3D
>
> The initial size of 8,000,000 bytes was chosen after testing the curre= nt
> 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 s= ize
increase was a one-time "scaling" to grant time for more decentra= lizing
solutions to develop'

Comments?

Consensus is that this proces= s is too painful to go through once a year.=C2=A0 I agree.

If you disagree and would like to see a Blocksize Council meet onc= e 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 ho= w their decrees are enforced.....
=C2=A0

In particular, if bandwidth scaling doesn't go according to your plan,<= br> 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 tha= t:

Lat= ency/bandwidth matter for miners.=C2=A0 Low latency, high bandwidth is bett= er. However, miners with bad connectivity can simply create smaller blocks.= ..

...= until transaction fees become significant.=C2=A0 But by the time that happ= ens, protocol optimizations of block propagation will make the block size a= n insignificant term in the "how profitable is it to mine in THIS part= icular place on the Internet / part of the world" equation.=C2=A0

(Reference= :=C2=A0https://www.mail-archive.com/bitcoin-developme= nt@lists.sourceforge.net/msg08224.html )

So: for the immediate future, there = is no problem. And in the long term, there is no problem.

--
--
Gavi= n Andresen
--047d7b34391acb25c705193501cb--