From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yqkec-0000Kr-8j for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 15:57:34 +0000 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; Received: from mail-wi0-f171.google.com ([209.85.212.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yqkeb-0007bp-87 for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 15:57:34 +0000 Received: by widdi4 with SMTP id di4so32342282wid.0 for ; Fri, 08 May 2015 08:57:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.207 with SMTP id a15mr7450959wik.2.1431100647228; Fri, 08 May 2015 08:57:27 -0700 (PDT) Received: by 10.27.12.78 with HTTP; Fri, 8 May 2015 08:57:27 -0700 (PDT) In-Reply-To: <16096345.A1MpJQQkRW@crushinator> References: <16096345.A1MpJQQkRW@crushinator> Date: Fri, 8 May 2015 18:57:27 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Dev Content-Type: multipart/alternative; boundary=e89a8f6473ebb74ad005159415f3 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (alex.mizrahi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yqkeb-0007bp-87 Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 15:57:34 -0000 --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
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.

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).
Once competitors close do= wn 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 bette= r 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--