Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9D6ED8AD for ; Thu, 6 Aug 2015 14:06:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C49B312A for ; Thu, 6 Aug 2015 14:06:04 +0000 (UTC) Received: by iggf3 with SMTP id f3so11962637igg.1 for ; Thu, 06 Aug 2015 07:06:03 -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=74rwTrybUDG7nyHWvLsdruyT65VgbMxoMrsMG2S39Jw=; b=bEnUmzlrlCuC0yYqQgg29QOj+XhYOxJU1eeiXaZ1XXLHevkUJePbHbGCHy+NPtRLgj 6YsSJHbfO71jrg7Qw/1qGiOTX+5Y7GREScYkbHRFYl9ZN+PZ/HtzZyEyO/+3xneS8roP iqw0tv3Js4ga/f2SkUvlQMM8LWbk+thmkmdbxLVHQnOTKjwM5bMLXih3HHvORuv7czN5 EXgCcoML8QAcYxnb6IO6t1w+rBkVZEyFEvcSK158pp0ShV+Cs0XERexOOoRe34lfr5jZ f90Jvt+nFEuQJ53d6WMpun1n7NOtxA+AOuE+N/MtgrOz9Dg0FrfocbCIuSwfxWP3fPvn cAJQ== MIME-Version: 1.0 X-Received: by 10.50.134.226 with SMTP id pn2mr4064707igb.21.1438869963648; Thu, 06 Aug 2015 07:06:03 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 6 Aug 2015 07:06:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 16:06:03 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=047d7b2e148d0fb531051ca5055e 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] Block size following technological growth 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: Thu, 06 Aug 2015 14:06:07 -0000 --047d7b2e148d0fb531051ca5055e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Aug 5, 2015 at 9:26 PM, Jorge Tim=C3=B3n < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This is a much more reasonable position. I wish this had been starting >> point of this discussion instead of "the block size limit must be >> increased as soon as possible or bitcoin will fail". >> > > It REALLY doesn't help the debate when you say patently false statements > like that. > > My first blog post on this issue is here: > http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent > > ... and I NEVER say "Bitcoin will fail". I say: > > "If the number of transactions waiting gets large enough, the end result > will be an over-saturated network, busy doing nothing productive. I don= =E2=80=99t > think that is likely=E2=80=93 it is more likely people just stop using Bi= tcoin > because transaction confirmation becomes increasingly unreliable." > But you seem to consider that a bad thing. Maybe saying that you're claiming that this equals Bitcoin failing is an exaggeration, but you do believe that evolving towards an ecosystem where there is competition for block space is a bad thing, right? I don't agree that "Not everyone is able to use the block chain for every use case" is the same thing as "People stop using Bitcoin". People are already not using it for every use case. Here is what my proposed BIP says: "No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy." --=20 Pieter --047d7b2e148d0fb531051ca5055e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin= -dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Aug 5, 2015 at 9:26 PM, Jorge= Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org= > wrote:
This is a much more reasonable position. I wish this had been star= ting
point of this discussion instead of "the block size limit must be
increased as soon as possible or bitcoin will fail".

It REALLY doesn't help the debate when you say patent= ly false statements like that.

My first blog post on this issue is here:
=C2=A0=C2=A0http://gavina= ndresen.ninja/why-increasing-the-max-block-size-is-urgent

... and I NEVER say= "Bitcoin will fail".=C2=A0 I say:

"If the number o= f transactions waiting gets large enough, the end result will be an over-sa= turated network, busy doing nothing productive. I don=E2=80=99t think that = is likely=E2=80=93 it is more likely people just stop using Bitcoin because= transaction confirmation becomes increasingly unreliable."
<= /blockquote>

But you seem to consider that a bad thing. = Maybe saying that you're claiming that this equals Bitcoin failing is a= n exaggeration, but you do believe that evolving towards an ecosystem where= there is competition for block space is a bad thing, right?

<= div>I don't agree that "Not everyone is able to use the block chai= n for every use case" is the same thing as "People stop using Bit= coin". People are already not using it for every use case.

Here is what my proposed BIP says: "No hard forking = change that relaxes the block size limit can be=20 guaranteed to provide enough space for every possible demand - or even=20 any particular demand - unless strong centralization of the mining=20 ecosystem is expected. Because of that, the development of a fee market=20 and the evolution towards an ecosystem that is able to cope with block=20 space competition should be considered healthy."

--
<= div>Pieter

--047d7b2e148d0fb531051ca5055e--