/ f1 / 0a28435cc5c9f50ef774e8640f03fa96d59b9a
0a28435cc5c9f50ef774e8640f03fa96d59b9a
  1  Return-Path: <gavinandresen@gmail.com>
  2  Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
  3  	[172.17.192.35])
  4  	by mail.linuxfoundation.org (Postfix) with ESMTPS id 406B94D3
  5  	for <bitcoin-dev@lists.linuxfoundation.org>;
  6  	Fri,  7 Aug 2015 15:55:12 +0000 (UTC)
  7  X-Greylist: whitelisted by SQLgrey-1.7.6
  8  Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
  9  	[209.85.217.172])
 10  	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94435147
 11  	for <bitcoin-dev@lists.linuxfoundation.org>;
 12  	Fri,  7 Aug 2015 15:55:11 +0000 (UTC)
 13  Received: by lbbpo9 with SMTP id po9so63541710lbb.2
 14  	for <bitcoin-dev@lists.linuxfoundation.org>;
 15  	Fri, 07 Aug 2015 08:55:09 -0700 (PDT)
 16  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 17  	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 18  	:cc:content-type;
 19  	bh=0N/4eiNNSTeartgxZzJ6sdwsonj7Rachs/DbcEP+b7k=;
 20  	b=lMN6PuQrYmS8dk/9BXTO2kfp5VU0gnZ/HYEmiPIbrnn6rNl+4UIWy8+Eba6QENwYmp
 21  	UnABuUFQGX0e6T8ur/FF6Gg9qbuvpedYime09BOb1V4Hn3HYQyVjP6QKaYoWhKs4q4ex
 22  	Ojvr49UzXlhGhh19Y7aWoShAwC2H8rybYmSWAr+w2SVEeWf+nNoRhZSzHrdoZ01tLl5r
 23  	DPiYIuH9Gg4N2BXzGMzJFy5eljikY3Q0F9zyY/rUBpcCkZSteCniUT8YQcoqzPh3wet1
 24  	nbKb05dAeC45Tv8TCiunyJqbGRVHfqUznNXokX4RMW9QdYOJqV5wi40ImamDHl3lVAww
 25  	W3/w==
 26  MIME-Version: 1.0
 27  X-Received: by 10.152.115.132 with SMTP id jo4mr8254623lab.113.1438962909700; 
 28  	Fri, 07 Aug 2015 08:55:09 -0700 (PDT)
 29  Received: by 10.25.143.195 with HTTP; Fri, 7 Aug 2015 08:55:09 -0700 (PDT)
 30  In-Reply-To: <CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
 31  References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
 32  	<CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
 33  Date: Fri, 7 Aug 2015 11:55:09 -0400
 34  Message-ID: <CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
 35  From: Gavin Andresen <gavinandresen@gmail.com>
 36  To: Pieter Wuille <pieter.wuille@gmail.com>
 37  Content-Type: multipart/alternative; boundary=001a11c366d213e7c9051cbaa9de
 38  X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
 39  	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
 40  	autolearn=ham version=3.3.1
 41  X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
 42  	smtp1.linux-foundation.org
 43  Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
 44  Subject: Re: [bitcoin-dev] Fees and the block-finding process
 45  X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
 46  X-Mailman-Version: 2.1.12
 47  Precedence: list
 48  List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
 49  List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
 50  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
 51  List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
 52  List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
 53  List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
 54  List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
 55  	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
 56  X-List-Received-Date: Fri, 07 Aug 2015 15:55:12 -0000
 57  
 58  --001a11c366d213e7c9051cbaa9de
 59  Content-Type: text/plain; charset=UTF-8
 60  
 61  On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail.com>
 62  wrote:
 63  
 64  > I guess my question (and perhaps that's what Jorge is after): do you feel
 65  > that blocks should be increased in response to (or for fear of) such a
 66  > scenario.
 67  >
 68  
 69  I think there are multiple reasons to raise the maximum block size, and
 70  yes, fear of Bad Things Happening as we run up against the 1MB limit is one
 71  of the reasons.
 72  
 73  I take the opinion of smart engineers who actually do resource planning and
 74  have seen what happens when networks run out of capacity very seriously.
 75  
 76  
 77  And if so, if that is a reason for increase now, won't it be a reason for
 78  > an increase later as well? It is my impression that your answer is yes,
 79  > that this is why you want to increase the block size quickly and
 80  > significantly, but correct me if I'm wrong.
 81  >
 82  
 83  Sure, it might be a reason for an increase later. Here's my message to
 84  in-the-future Bitcoin engineers:  you should consider raising the maximum
 85  block size if needed and you think the benefits of doing so (like increased
 86  adoption or lower transaction fees or increased reliability) outweigh the
 87  costs (like higher operating costs for full-nodes or the disruption caused
 88  by ANY consensus rule change).
 89  
 90  
 91  -- 
 92  --
 93  Gavin Andresen
 94  
 95  --001a11c366d213e7c9051cbaa9de
 96  Content-Type: text/html; charset=UTF-8
 97  Content-Transfer-Encoding: quoted-printable
 98  
 99  <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
100  ri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span dir=3D"ltr">&lt;<a href=3D=
101  "mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
102  /a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
103  0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
104  iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess my questio=
105  n (and perhaps that&#39;s what Jorge is after): do you feel that blocks sho=
106  uld be increased in response to (or for fear of) such a scenario. </div></d=
107  iv></div></div></blockquote><div><br></div><div>I think there are multiple =
108  reasons to raise the maximum block size, and yes, fear of Bad Things Happen=
109  ing as we run up against the 1MB limit is one of the reasons.</div><div><br=
110  ></div><div>I take the opinion of smart engineers who actually do resource =
111  planning and have seen what happens when networks run out of capacity very =
112  seriously.</div><div><br></div><div><br></div><blockquote class=3D"gmail_qu=
113  ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
114  "><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
115  iv>And if so, if that is a reason for increase now, won&#39;t it be a reaso=
116  n for an increase later as well? It is my impression that your answer is ye=
117  s, that this is why you want to increase the block size quickly and signifi=
118  cantly, but correct me if I&#39;m wrong. <br></div></div></div></div></bloc=
119  kquote><div><br></div><div>Sure, it might be a reason for an increase later=
120  . Here&#39;s my message to in-the-future Bitcoin engineers: =C2=A0you shoul=
121  d consider raising the maximum block size if needed and you think the benef=
122  its of doing so (like increased adoption or lower transaction fees or incre=
123  ased reliability) outweigh the costs (like higher operating costs for full-=
124  nodes or the disruption caused by ANY consensus rule change).</div></div><d=
125  iv><br></div><div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gav=
126  in Andresen<br></div><div class=3D"gmail_signature"><br></div>
127  </div></div>
128  
129  --001a11c366d213e7c9051cbaa9de--
130