MIME-Version: 1.0
In-Reply-To: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Sat, 10 Dec 2016 15:12:25 -0800
Message-ID: <CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com>
To: "t. khan" <teekhan42@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eb2c2fabbcc054356004a
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
 (aka Block75)
Precedence: list

--001a113eb2c2fabbcc054356004a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Put another way: let=E2=80=99s stop thinking about what the max block siz=
e should
> be and start thinking about how full we want the average block to be
> regardless of size. Over the last year, we=E2=80=99ve had averages of 75%=
 or
> higher, so aiming for 75% full seems reasonable, hence naming this concep=
t
> =E2=80=98Block75=E2=80=99.
>

That's effectively making the blocksize limit completely uncapped and only
preventing spikes, and even in the case of spikes it doesn't differentiate
between 'real' traffic and low value spam attacks. It suffers from the same
fundamental problems as bitcoin unlimited: There are in the end no
transaction fees, and inevitably some miners will want to impose some cap
on block size for practical purposes, resulting in a fork.

Difficulty adjustment works because there's a clear goal of having a
certain rate of making new blocks. Without a target to attempt automatic
adjustment makes no sense.

--001a113eb2c2fabbcc054356004a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><br><div>Put another way: let=
=E2=80=99s stop thinking about what the max block size should be and start =
thinking about how full we want the average block to be regardless of size.=
 Over the last year, we=E2=80=99ve had averages of 75% or higher, so aiming=
 for 75% full seems reasonable, hence naming this concept =E2=80=98Block75=
=E2=80=99.<br></div></div></div></div></blockquote><div><br></div><div>That=
&#39;s effectively making the blocksize limit completely uncapped and only =
preventing spikes, and even in the case of spikes it doesn&#39;t differenti=
ate between &#39;real&#39; traffic and low value spam attacks. It suffers f=
rom the same fundamental problems as bitcoin unlimited: There are in the en=
d no transaction fees, and inevitably some miners will want to impose some =
cap on block size for practical purposes, resulting in a fork.</div><div><b=
r></div><div>Difficulty adjustment works because there&#39;s a clear goal o=
f having a certain rate of making new blocks. Without a target to attempt a=
utomatic adjustment makes no sense.</div></div></div></div>

--001a113eb2c2fabbcc054356004a--