Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yy1hh-00028F-Ge for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:34:49 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.41 as permitted sender) client-ip=74.125.82.41; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f41.google.com; Received: from mail-wg0-f41.google.com ([74.125.82.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yy1hg-0001E1-Bd for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:34:49 +0000 Received: by wgv5 with SMTP id 5so42621105wgv.1 for ; Thu, 28 May 2015 10:34:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.9.161 with SMTP id a1mr7285438wjb.39.1432834482378; Thu, 28 May 2015 10:34:42 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 10:34:42 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Thu, 28 May 2015 19:34:42 +0200 X-Google-Sender-Auth: -pek2aHpQqLLhgbBCbFdkEPTfEw Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=047d7b5d34fa581ebf051727c610 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: 1Yy1hg-0001E1-Bd 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:34:49 -0000 --047d7b5d34fa581ebf051727c610 Content-Type: text/plain; charset=UTF-8 > > Twenty is scary. > To whom? The only justification for the max size is DoS attacks, right? Back when Bitcoin had an average block size of 10kb, the max block size was 100x the average. Things worked fine, nobody was scared. The max block size is really a limit set by hardware capability, which is something that's difficult to measure in software. I think I preferred your original formula that guesstimated based on previous trends to one that just tries to follow some average. As noted, many miners just accept the defaults. With your proposed change their target would effectively *drop* from 1mb to 800kb today, which seems crazy. That's the exact opposite of what is needed right now. I am very skeptical about this idea. > I don't think us developers should be deciding things like whether or not > fees are too high, too low, > Miners can already attempt to apply fee pressure by just not mining transactions that they feel don't pay enough. Some sort of auto-cartel that attempts to restrict supply based on everyone looking at everyone else feels overly complex and prone to strange situations: it looks a lot like some kind of Mexican standoff to me. Additionally, the justification for the block size limit was DoS by someone mining "troll blocks". It was never meant to be about fee pressure. Resource management inside Bitcoin Core is certainly something to be handled by developers. --047d7b5d34fa581ebf051727c610 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Twenty is scary.

To whom? The only justification = for the max size is DoS attacks, right? Back when Bitcoin had an average bl= ock size of 10kb, the max block size was 100x the average. Things worked fi= ne, nobody was scared.

The max block size is reall= y a limit set by hardware capability, which is something that's difficu= lt to measure in software. I think I preferred your original formula that g= uesstimated based on previous trends to one that just tries to follow some = average.

As noted, many miners just accept the def= aults. With your proposed change their target would effectively drop= =C2=A0from 1mb to 800kb today, which seems crazy. That's the exact oppo= site of what is needed right now.

I am very skepti= cal about this idea.
=C2=A0
I don't think us developers should be deci= ding things like whether or not fees are too high, too low,

Miners can already attempt to apply fee pressu= re by just not mining transactions that they feel don't pay enough. Som= e sort of auto-cartel that attempts to restrict supply based on everyone lo= oking at everyone else feels overly complex and prone to strange situations= : it looks a lot like some kind of Mexican standoff to me.

Additionally, the justification for the block size limit was DoS b= y someone mining "troll blocks". It was never meant to be about f= ee pressure. Resource management inside Bitcoin Core is certainly something= to be handled by developers.
--047d7b5d34fa581ebf051727c610--