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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yy1FF-0004Ef-GP for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:05:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.174 as permitted sender) client-ip=209.85.212.174; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f174.google.com; Received: from mail-wi0-f174.google.com ([209.85.212.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yy1FE-0001gE-F0 for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:05:25 +0000 Received: by wicmx19 with SMTP id mx19so129880992wic.0 for ; Thu, 28 May 2015 10:05:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.99.69 with SMTP id eo5mr6323536wib.92.1432832718463; Thu, 28 May 2015 10:05:18 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 10:05:18 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Thu, 28 May 2015 19:05:18 +0200 X-Google-Sender-Auth: QXn0vz8y9Bt0u-melqUTTd5Fuxg Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d04428fcc34e8700517275d71 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Yy1FE-0001gE-F0 Cc: Bitcoin Dev 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: Thu, 28 May 2015 17:05:25 -0000 --f46d04428fcc34e8700517275d71 Content-Type: text/plain; charset=UTF-8 > > Even a 2x rule (implying 800K max blocks) would, today, be squeezing out > transactions / putting pressure to increase fees ..... > > So my straw-man proposal would be: max size 2x average size over last 144 > blocks, calculated at every block. > Isn't that a step backwards, then? I see no reason for fee pressure to exist at the moment. All it's doing is turning away users for no purpose: mining isn't supported by fees, and the tiny fees we use right now seem to be good enough to stop penny flooding. Why not set the max size to be 20x the average size? Why 2x, given you just pointed out that'd result in blocks shrinking rather than growing. --f46d04428fcc34e8700517275d71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even a 2x rule (implying 800K max blocks) would= , today, be squeezing out transactions / putting pressure to increase fees = .....=C2=A0

So my straw-man proposal would be: =C2= =A0max size 2x average size over last 144 blocks, calculated at every block= .

Isn't tha= t a step backwards, then? I see no reason for fee pressure to exist at the = moment. All it's doing is turning away users for no purpose: mining isn= 't supported by fees, and the tiny fees we use right now seem to be goo= d enough to stop penny flooding.

Why not set the m= ax size to be 20x the average size? Why 2x, given you just pointed out that= 'd result in blocks shrinking rather than growing.
--f46d04428fcc34e8700517275d71--