path: root/46/a879a6b438e805892e17356cd729b0641461ef

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 7C643E95
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Sep 2015 13:52:00 +0000 (UTC)
Received: by obqa2 with SMTP id a2so83571912obq.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
	<CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com>
	<CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com>
	<CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
Date: Tue, 8 Sep 2015 09:52:00 -0400
Message-ID: <CAAre=yTP07HQZesCgyAVQ9UqyJ98UhLLa8cTPNi7F+e6Ht05fg@mail.gmail.com>
From: Ivan Brightly <ibrightly@gmail.com>
To: Adam Back <adam@cypherspace.org>
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 <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 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 <adam@cypherspace.org> 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
> <bitcoin-dev@lists.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
> 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.
> >
> >
> > _______________________________________________
> > 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

<div dir=3D"ltr">Agreed. For this reason, the scaling BIPs which don&#39;t =
allow for easy gaming such as BIP101, your proposal or Pieter&#39;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><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Sep 8, 201=
5 at 9:13 AM, Adam Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypher=
space.org" target=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The maximum block-size is one that can be fi=
lled at zero-cost by<br>
miners, and so allows some kinds of amplification of selfish-mining<br>
related attacks.<br>
<br>
Adam<br>
<br>
<br>
On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; This is true, but miners already control block size through soft caps.=
<br>
&gt; Miners are fully capable of producing smaller blocks regardless of the=
 max<br>
&gt; block limit, with or without collusion. Arguably, there is no need to =
ever<br>
&gt; reduce the max block size unless technology advances for some reason r=
everse<br>
&gt; course - aka, WW3 takes a toll on the internet and the average bandwid=
th<br>
&gt; available halves. The likelihood of significant technology contraction=
 in<br>
&gt; the near future seems rather unlikely and is more broadly problematic =
for<br>
&gt; society than bitcoin specifically.<br>
&gt;<br>
&gt; The only reason for reducing the max block limit other than technology=
<br>
&gt; availability is if you think that this is what will produce the fee ma=
rket,<br>
&gt; which is back to an economic discussion - not a technology scaling<br>
&gt; discussion.<br>
&gt;<br>
&gt; On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; but allow meaningful relief to transaction volume pressure in=
 response<br>
&gt;&gt; &gt; to true market demand<br>
&gt;&gt;<br>
&gt;&gt; If blocksize can only increase then it&#39;s like a market that on=
ly goes<br>
&gt;&gt; up which is unrealistic. Transaction will volume ebb and flow<br>
&gt;&gt; significantly. Some people have been looking at transaction volume=
<br>
&gt;&gt; charts over time and all they can see is an exponential curve whic=
h<br>
&gt;&gt; they think will go on forever, yet nothing goes up forever and it =
will<br>
&gt;&gt; go through significant trend cycles (like everything does). If you=
<br>
&gt;&gt; dont want to hurt the fee market, the blocksize has to be elastic =
and<br>
&gt;&gt; allow contraction as well as expansion.<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--089e013a07788e543f051f3cabec--