Return-Path: <ibrightly@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 19CD2E8D for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 8 Sep 2015 12:28:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A4ADF201 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 8 Sep 2015 12:28:56 +0000 (UTC) Received: by oibi136 with SMTP id i136so57606411oib.3 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 08 Sep 2015 05:28:56 -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=Pcrw2dSdAxoTaD/yo4M/bzcAHdKd4sGY4S+HqhNum8I=; b=RIaf1o8jQUeIe3jGsEIni6GnDY8NNNDXvu8FnH4OFGvt7QLSumy3W/wMooJMJ43Dwh dgSgdtsna68IdpG2Y+pTvwfHkVdNqvY8F00p6rMwUyS3rPKYmktcrFUn8ZymqwwOSHhn aF7VMIDznac3TJ42ItGjUkTByguUoK32lpAqjrbsoDnznk5eeE2o7zOLZSWlbfyz2GLu /W2JDzP5mF6guC3BASZJgbDLWfMa9vBYvT3E3KIulZjvtBWFsG29z7w6oFRRlNoiW4iA l1Nh1LTHpbj5j4btFs9jhK+9hw+ACpefkXcMDK0Z7q5Nw/vFdmwxH0ZUj0Js0FL8c+uE Gk8g== MIME-Version: 1.0 X-Received: by 10.202.78.82 with SMTP id c79mr18992362oib.15.1441715336106; Tue, 08 Sep 2015 05:28:56 -0700 (PDT) Received: by 10.76.86.4 with HTTP; Tue, 8 Sep 2015 05:28:56 -0700 (PDT) In-Reply-To: <CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com> References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com> <CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com> Date: Tue, 8 Sep 2015 08:28:56 -0400 Message-ID: <CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com> From: Ivan Brightly <ibrightly@gmail.com> To: Btc Drak <btcdrak@gmail.com> Content-Type: multipart/alternative; boundary=001a1134e06679db6a051f3b82e2 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 <bitcoin-dev@lists.linuxfoundation.org>, Washington Sanchez <washington.sanchez@gmail.com> Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 08 Sep 2015 12:28:57 -0000 --001a1134e06679db6a051f3b82e2 Content-Type: text/plain; charset=UTF-8 This is true, but miners already control block size through soft caps. Miners are fully capable of producing smaller blocks regardless of the max block limit, with or without collusion. Arguably, there is no need to ever reduce the max block size unless technology advances for some reason reverse course - aka, WW3 takes a toll on the internet and the average bandwidth available halves. The likelihood of significant technology contraction in the near future seems rather unlikely and is more broadly problematic for society than bitcoin specifically. The only reason for reducing the max block limit other than technology availability is if you think that this is what will produce the fee market, which is back to an economic discussion - not a technology scaling discussion. On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > but allow meaningful relief to transaction volume pressure in response > to true market demand > > If blocksize can only increase then it's like a market that only goes > up which is unrealistic. Transaction will volume ebb and flow > significantly. Some people have been looking at transaction volume > charts over time and all they can see is an exponential curve which > they think will go on forever, yet nothing goes up forever and it will > go through significant trend cycles (like everything does). If you > dont want to hurt the fee market, the blocksize has to be elastic and > allow contraction as well as expansion. > --001a1134e06679db6a051f3b82e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">This is true, but miners alread= y control block size through soft caps. Miners are fully capable of produci= ng smaller blocks regardless of the max block limit, with or without collus= ion. Arguably, there is no need to ever reduce the max block size unless te= chnology advances for some reason reverse course - aka, WW3 takes a toll on= the internet and the average bandwidth available halves. The likelihood of= significant technology contraction in the near future seems rather unlikel= y and is more broadly problematic for society than bitcoin specifically.</d= iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The only= reason for reducing the max block limit other than technology availability= is if you think that this is what will produce the fee market, which is ba= ck to an economic discussion - not a technology scaling discussion.</div><d= iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Sep 8, 2015= at 4:49 AM, Btc Drak via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mail= to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis= ts.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex">> but allow meaningful relief to transaction volume pressure in resp= onse to true market demand<br> <br> If blocksize can only increase then it's like a market that only goes<b= r> up which is unrealistic. Transaction will volume ebb and flow<br> significantly. Some people have been looking at transaction volume<br> charts over time and all they can see is an exponential curve which<br> they think will go on forever, yet nothing goes up forever and it will<br> go through significant trend cycles (like everything does). If you<br> dont want to hurt the fee market, the blocksize has to be elastic and<br> allow contraction as well as expansion.<br></blockquote></div></div></div> --001a1134e06679db6a051f3b82e2--