Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 105EE25A for ; Mon, 10 Aug 2015 14:12:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1DA8E8 for ; Mon, 10 Aug 2015 14:12:07 +0000 (UTC) Received: by lbbpu9 with SMTP id pu9so68369178lbb.3 for ; Mon, 10 Aug 2015 07:12:06 -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=diOO+/RQp2k+plNz7B0LPWG3WL1TaJvqcavWnb4Inaw=; b=ezOzDN5KQ0ZaFh6wUWTF5Svf3DKzE3mwg+eRqEROuv3+j7CT+oS8SAj5qexJAa6Kz9 xf6CoNrl11V8aOYMkvdOcgEJ3DOQABlYsmF65WpuZpfnITXaz81h+Fo8TpE2hpIkVUik USoIFLbaVo+RcbB5FpQ/C/AfXuH6hrjvE/XItmnzW2I2SRQ5nf/Ejtvrugbr443biB5+ +1nwclWcc/2ZvyFd57nooha8oVE1UcoOYtTugHEKRlXm6jXW77C4DqKUxtjo/GOH75EG pob3a+1oDjQ1tgRPinQHT8+ZJgWv/0fJlvMHBu9PfvgSPWcEl2533t8MI0d+hr8ANoo7 9Vfg== MIME-Version: 1.0 X-Received: by 10.152.43.41 with SMTP id t9mr20304444lal.4.1439215925890; Mon, 10 Aug 2015 07:12:05 -0700 (PDT) Received: by 10.25.62.14 with HTTP; Mon, 10 Aug 2015 07:12:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2015 10:12:05 -0400 Message-ID: From: Gavin Andresen To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a11c27f400493b6051cf59221 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 Subject: Re: [bitcoin-dev] Fees and the block-finding process 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: Mon, 10 Aug 2015 14:12:09 -0000 --001a11c27f400493b6051cf59221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 7, 2015 at 1:33 PM, Jorge Tim=C3=B3n wrote: > > On Aug 7, 2015 5:55 PM, "Gavin Andresen" wrote: > > > > I think there are multiple reasons to raise the maximum block size, and > yes, fear of Bad Things Happening as we run up against the 1MB limit is o= ne > of the reasons. > > What are the other reasons? > > > I take the opinion of smart engineers who actually do resource planning > and have seen what happens when networks run out of capacity very serious= ly. > > When "the network runs out of capacity" (when we hit the limit) do we > expect anything to happen apart from minimum market fees rising (above > zero)? > Obviously any consequences of fees rising are included in this concern. > It is frustrating to answer questions that we answered months ago, especially when I linked to these in response to your recent "increase advocates say that not increasing the max block size will KILL BITCOIN" false claim: http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent https://medium.com/@octskyward/crash-landing-f5cc19908e32 Executive summary: when networks get over-saturated, they become unreliable. Unreliable is bad. Unreliable and expensive is extra bad, and that's where we're headed without an increase to the max block size. RE: the recent thread about "better deal with that type of thing now rather than later" : exactly the same argument can be made about changes needed to support a larger block size-- "better to do that now than to do that later." I don't think either of those arguments are very convincing. --=20 -- Gavin Andresen --001a11c27f400493b6051cf59221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 7, 2015 at 1:33 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:


On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen@gmail.com> wr= ote:
>
> I think there are multiple reasons to raise the maximum block size, an= d yes, fear of Bad Things Happening as we run up against the 1MB limit is o= ne of the reasons.

What are the other reasons?

> I take the opinion of smart engineers who actually do r= esource planning and have seen what happens when networks run out of capaci= ty very seriously.

When "the network runs out of capacity" (wh= en we hit the limit) do we expect anything to happen apart from minimum mar= ket fees rising (above zero)?
Obviously any consequences of fees rising are included in this concern.

It is frustrating to answer questions that we answered m= onths ago, especially when I linked to these in response to your recent &qu= ot;increase advocates say that not increasing the max block size will KILL = BITCOIN" false claim:
=C2=A0=C2=A0http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent<= /a>
=C2=A0=C2=A0https://medium.com/@octskyward/c= rash-landing-f5cc19908e32

Executive summary: when networks get over-saturated= , they become unreliable.=C2=A0 Unreliable is bad.

Unreliable and expensive is ex= tra bad, and that's where we're headed without an increase to the m= ax block size.

RE: the recent thread about "better deal with that type of th= ing now rather than later" : =C2=A0exactly the same argument can be ma= de about changes needed to support a larger block size-- "better to do= that now than to do that later." =C2=A0I don't think either of th= ose arguments are very convincing.


--
--
Gavin Andresen

--001a11c27f400493b6051cf59221--