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 7C643E95 for ; Tue, 8 Sep 2015 13:52:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D88261DA for ; Tue, 8 Sep 2015 13:52:00 +0000 (UTC) Received: by obqa2 with SMTP id a2so83571912obq.3 for ; Tue, 08 Sep 2015 06:52:00 -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=kJ0aE3Io0Q3qIsXDqEtlKRWXHYKnysLpNdQ8m1o6dV4=; b=Sich6dVJKRcKwamRajDdkMSpvU/k/xK7H+S0Q0SvpgviX9AbEIyHKlgQkkfT3EHu7k skhGOCqEsRDkU6a45XURdk4BfR6b8FZy2vmcIaeY6Umb5v2rVkcfhIscrs+G9b5IJcsg jJh7HDe1y1F8IV4FUn7n9pAYhNFIKGwCk3GHAzvAwN/4JuzgyOiTe1957ccHNs4iBYgg SVWojL00ThDBPnY0ZO/ZHX61dklKsfMjEHiwjxy3OQGoH+3fyOz93NJXCvbN5jrMlGDH lEkzyJjdsaT3n4ODOaB61Knao7YV4f2IaEnhwI6utpxepDJgco6xNDn9iyGiuWIb8JUE mflg== MIME-Version: 1.0 X-Received: by 10.182.120.72 with SMTP id la8mr20076243obb.7.1441720320282; Tue, 08 Sep 2015 06:52:00 -0700 (PDT) Received: by 10.76.86.4 with HTTP; Tue, 8 Sep 2015 06:52:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Sep 2015 09:52:00 -0400 Message-ID: From: Ivan Brightly To: Adam Back Content-Type: multipart/alternative; boundary=089e013a07788e543f051f3cabec 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 , Washington Sanchez 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 13:52:01 -0000 --089e013a07788e543f051f3cabec Content-Type: text/plain; charset=UTF-8 Agreed. For this reason, the scaling BIPs which don't allow for easy gaming such as BIP101, your proposal or Pieter's are preferable for their predictability and simplicity. Changing the fundamental rules for Bitcoin is supposed to be hard - why give this power up to a subsection of the ecosystem in order to make it easier to change or game? On Tue, Sep 8, 2015 at 9:13 AM, Adam Back wrote: > The maximum block-size is one that can be filled at zero-cost by > miners, and so allows some kinds of amplification of selfish-mining > related attacks. > > Adam > > > On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev > wrote: > > 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 > > 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. > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --089e013a07788e543f051f3cabec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed. For this reason, the scaling BIPs which don't = allow for easy gaming such as BIP101, your proposal or Pieter's are pre= ferable for their predictability and simplicity. Changing the fundamental r= ules for Bitcoin is supposed to be hard - why give this power up to a subse= ction of the ecosystem in order to make it easier to change or game?
<= div class=3D"gmail_extra">
On Tue, Sep 8, 201= 5 at 9:13 AM, Adam Back <adam@cypherspace.org> wrote:
=
The maximum block-size is one that can be fi= lled at zero-cost by
miners, and so allows some kinds of amplification of selfish-mining
related attacks.

Adam


On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> 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 r= everse
> course - aka, WW3 takes a toll on the internet and the average bandwid= th
> 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 ma= rket,
> 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-d= ev@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 on= ly 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 whic= h
>> 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--089e013a07788e543f051f3cabec--