MIME-Version: 1.0
Date: Tue, 18 Aug 2015 08:38:05 +0200
Message-ID: <CAAUq486afiWsDzMhGsYmX3v5AsWmaHNq9taS-azUodg5cWWRKA@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114d6f181f3cab051d902997
Subject: [bitcoin-dev] Simplifying the blocksize limit debate
Precedence: list

--001a114d6f181f3cab051d902997
Content-Type: text/plain; charset=UTF-8

I'm going to list a few assumtions / observations / understandings around
this debate. Please point out the incorrect ones.

* Most developers here agree that 1 MB is not a magic constant and that the
limit has to increase eventually.

* Most developers want to reduce the amount of policy decisions
bitcoin-core makes as much as possible.

* The most conservative option for the 4 billion dollar system that is
bitcoin is to keep the limit.

* Technological growth in bandwidth, cpu and storage exists and relative to
that growth, the blocksize limit is effectively decreased. Keeping the
limit as it is today, or was five years ago, means we need to adjust for
technological growth.

* Doing so will not reduce current decentralization, however measured.

* Increasing the blocksize limit will always require a hard-fork.
Decreasing, or stopping the growth of the blocksize limit will always be
possible via soft-fork.

* Problems arising from underestimating the need for a larger blocksize
limit are increasingly harder to fix. Problems arising from a limit that is
getting too high are more easy to fix.

* This means we can be optimistic when estimating future technological
growth.

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

<div dir=3D"ltr"><div>I&#39;m going to list a few assumtions / observations=
 / understandings around this debate. Please point out the incorrect ones.<=
br></div><div><br></div><div>* Most developers here agree that 1 MB is not =
a magic constant and that the limit has to increase eventually.</div><div><=
br></div><div>* Most developers want to reduce the amount of policy decisio=
ns bitcoin-core makes as much as possible.</div><div><br></div><div>* The m=
ost conservative option for the 4 billion dollar system that is bitcoin is =
to keep the limit.</div><div><br></div><div>* Technological growth in bandw=
idth, cpu and storage exists and relative to that growth, the blocksize lim=
it is effectively decreased. Keeping the limit as it is today, or was five =
years ago, means we need to adjust for technological growth.</div><div><br>=
</div><div>* Doing so will not reduce current decentralization, however mea=
sured.</div><div><br></div><div>* Increasing the blocksize limit will alway=
s require a hard-fork. Decreasing, or stopping the growth of the blocksize =
limit will always be possible via soft-fork.</div><div><br></div><div>* Pro=
blems arising from underestimating the need for a larger blocksize limit ar=
e increasingly harder to fix. Problems arising from a limit that is getting=
 too high are more easy to fix.</div><div><br></div><div><div>* This means =
we can be optimistic when estimating future technological growth.</div><div=
><br></div></div></div>

--001a114d6f181f3cab051d902997--