MIME-Version: 1.0
In-Reply-To: <1E68C70C-B33E-4414-B48B-7A497B59C893@gmail.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
	<20150627074259.GA25420@amethyst.visucore.com>
	<20150627095501.C59B541A40@smtp.hushmail.com>
	<20150627100400.GC25420@amethyst.visucore.com>
	<20150627102912.06E2641A3E@smtp.hushmail.com>
	<CABm2gDpnzjph5SKTf+8GWgwe+njS=k2GNm9uL73RC-EV=Y5wug@mail.gmail.com>
	<1E68C70C-B33E-4414-B48B-7A497B59C893@gmail.com>
Date: Sat, 27 Jun 2015 13:43:55 +0200
Message-ID: <CABm2gDqvSCCTgjifpxZAy6wgb_f3yKp9-8P2d=n9fWdWxSGayA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Precedence: list

On Sat, Jun 27, 2015 at 1:18 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> The economic policy=E2=80=99s status quo has been to avoid fee pressure. =
But the consensus status quo obviously is not to have a hard fork.
>
> There=E2=80=99s clearly a contradiction between these two policies, which=
 is a big part of the reason this issue has come to this point. These two p=
olicies are fundamentally at odds.

Ok, so then the decision is to either change a policy or change a
consensus rule and then maintaining the status quo is simply not
possible.
Since per-node and per-wallet policies weren't universal anyway
(nobody can be forced to run the standard policy), making some changes
to the policy code of the different implementations that weren't
prepared for the current consensus rules (that includes bitcoin core)
seems orders of magnitude closer to "maintaining the status quo" than
a hardfork.
It's interesting to note that increasing the blocksize without fixing
the underlying problems that make it a perceived "need" will leave the
implementations unprepared for the new rules too (it is just
unprepared for ANY block size limit, not specifically unprepared for
1MB blocks).
So increasing the block size is actually the "lazy option" regardless
of how the "doing nothing option" is perceived by many uninformed
participants in the discussions.
Then I guess by "maintaining the status quo" some people just mean
"not fixing the known problems we have yet, leave it for later". Not
only some people propose to delay solving this problems: they don't
even want to be forced to fix them in 20 years!
That...or they just want to remove the block size limit entirely
forever, don't fear centralization, and are not being clear about it.