MIME-Version: 1.0
In-Reply-To: <CABsx9T1nwastEoN12B2Y-TA2V1fYtDcm9-nkiOQNVhXmbCjcGQ@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
	<CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
	<CABm2gDq12a8p8+fB14nM5S8CVz=sdESMowZJUeKBwvx16WDSDQ@mail.gmail.com>
	<CABsx9T1nwastEoN12B2Y-TA2V1fYtDcm9-nkiOQNVhXmbCjcGQ@mail.gmail.com>
Date: Thu, 7 May 2015 20:05:22 +0200
Message-ID: <CABm2gDoF=JPOV=FqWBzXFp21=mJc4jJHGDKb1b5PYx28rGqeSw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen <gavinandresen@gmail.com> wr=
ote:
> Fee dynamics seems to come up over and over again in these discussions, w=
ith
> lots of talk and theorizing.
>
> I hope some data on what is happening with fees right now might help, so =
I
> wrote another blog post (with graphs, which can't be done in a mailing li=
st
> post):
>    http://gavinandresen.ninja/the-myth-of-not-full-blocks
>
> We don=E2=80=99t need 100% full one megabyte blocks to start to learn abo=
ut what is
> likely to happen as transaction volume rises and/or the one megabyte bloc=
k
> size limit is raised.

Ok, the fact that the fee increases the probability of getting
included faster already is a good thing, the graphs with the
probability of getting included in the next block were less important
to me.
Although scarce space (beyond what miners chose to limit by
themselves) would increase the fee competition, I didn't knew that
there is actually some competition happening already.
So I guess this diminishes the argument for maintaining the limits
longer to observe the results of more scarce space.
Still, I think maintaining a lower policy limit it's a good idea, even
if we decide not to use it to observe that soon.
For example, say we chose the 20 MB consensus limit, we can maintain
the policy limit at 1 MB or move it to 2 MB, and slowly moving it up
later as needed without requiring everyone to upgrade.
Of course, not all miners have to follow the standard policy, but at
least it's something.
So please take this as a suggestion to improve your proposal. You can
argue it like this "if we want to maintain the limits after the
hardfork or increase them slowly, for observing fee dynamics with more
scarce space or for any other reason, those limits can be partially
enforced by the standard policy". I mean, I think that could be a
reasonable compromise for that concrete line of arguments.