Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.171 as permitted sender)
	client-ip=209.85.212.171; envelope-from=alex.mizrahi@gmail.com;
	helo=mail-wi0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
References: <16096345.A1MpJQQkRW@crushinator>
Date: Fri, 8 May 2015 18:57:27 +0300
Message-ID: <CAE28kUSkQ6YWzkcqU9RqRkZzHUR_8wYj1pTxGF8Z4gp5SztdAA@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=e89a8f6473ebb74ad005159415f3
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

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

Adaptive schedules, i.e. those where block size limit depends not only on
block height, but on other parameters as well, are surely attractive in the
sense that the system can adapt to the actual use, but they also open a
possibility of a manipulation.

E.g. one of mining companies might try to bankrupt other companies by
making mining non-profitable. To do that they will accept transactions with
ridiculously low fees (e.g. 1 satoshi per transaction). Of course, they
will suffer losees themselves, but the they might be able to survive that
if they have access to financial resources. (E.g. companies backed by banks
and such will have an advantage).
Once competitors close down their mining operations, they can drive fees
upwards.

So if you don't want to open room for manipulation (which is very hard to
analyze), it is better to have a block size hard limit which depends only
on block height.
On top of that there might be a soft limit which is enforced by the
majority of miners.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">Adaptive schedules, i.e. those =
where block size limit depends not only on block height, but on other param=
eters as well, are surely attractive in the sense that the system can adapt=
 to the actual use, but they also open a possibility of a manipulation.</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">E.g. one =
of mining companies might try to bankrupt other companies by making mining =
non-profitable. To do that they will accept transactions with ridiculously =
low fees (e.g. 1 satoshi per transaction). Of course, they will suffer lose=
es themselves, but the they might be able to survive that if they have acce=
ss to financial resources. (E.g. companies backed by banks and such will ha=
ve an advantage).</div><div class=3D"gmail_extra">Once competitors close do=
wn their mining operations, they can drive fees upwards.</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">So if you don&#39;t want=
 to open room for manipulation (which is very hard to analyze), it is bette=
r to have a block size hard limit which depends only on block height.</div>=
<div class=3D"gmail_extra">On top of that there might be a soft limit which=
 is enforced by the majority of miners.</div></div>

--e89a8f6473ebb74ad005159415f3--