Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yy1mj-0004O5-DJ for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:40:01 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.209 as permitted sender) client-ip=65.55.34.209; envelope-from=raystonn@hotmail.com; helo=COL004-OMC4S7.hotmail.com; Received: from col004-omc4s7.hotmail.com ([65.55.34.209]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Yy1mi-0002na-6B for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:40:01 +0000 Received: from COL131-DS24 ([65.55.34.201]) by COL004-OMC4S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 28 May 2015 10:39:54 -0700 X-TMN: [VTljWkv8VaUkXd9N5IQmlOSDcxTLbGV3] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Gavin Andresen" , "Mike Hearn" References: <16096345.A1MpJQQkRW@crushinator> In-Reply-To: Date: Thu, 28 May 2015 10:39:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01D09932.93B6F540" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 28 May 2015 17:39:54.0567 (UTC) FILETIME=[4EC39570:01D0996D] X-Spam-Score: 1.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 (raystonn[at]hotmail.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.209 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails 1.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Yy1mi-0002na-6B Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction 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:40:01 -0000 ------=_NextPart_000_006C_01D09932.93B6F540 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that developers should avoid imposing economic policy. It is = dangerous for Bitcoin and the core developers themselves to become such = a central point of attack for those wishing to disrupt Bitcoin. My = opinion is these things are better left to a decentralized free market = anyhow. From: Gavin Andresen=20 Sent: Thursday, May 28, 2015 10:19 AM To: Mike Hearn=20 Cc: Bitcoin Dev=20 Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB = stepfunction On Thu, May 28, 2015 at 1:05 PM, Mike Hearn wrote: 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. Twenty is scary. And two is a very neutral number: if 50% of hashpower want the max size = to grow as fast as possible and 50% are dead-set opposed to any increase = in max size, then half produce blocks 2 times as big, half produce empty = blocks, and the max size doesn't change. If it was 20, then a small = minority of miners could force a max size increase. (if it is less than = 2, then a minority of minors can force the block size down) As for whether there "should" be fee pressure now or not: I have no = opinion, besides "we should make block propagation faster so there is no = technical reason for miners to produce tiny blocks." I don't think us = developers should be deciding things like whether or not fees are too = high, too low, ..... --=20 -- Gavin Andresen -------------------------------------------------------------------------= ------- -------------------------------------------------------------------------= ----- -------------------------------------------------------------------------= ------- _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ------=_NextPart_000_006C_01D09932.93B6F540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that developers should avoid imposing economic = policy.  It is=20 dangerous for Bitcoin and the core developers themselves to become such = a=20 central point of attack for those wishing to disrupt Bitcoin.  My = opinion=20 is these things are better left to a decentralized free market = anyhow.
 
 
Sent: Thursday, May 28, 2015 10:19 AM
Subject: Re: [Bitcoin-development] Proposed alternatives to = the 20MB=20 stepfunction
 
On Thu, May 28, 2015 at 1:05 PM, Mike Hearn = <mike@plan99.net> wrote:
Isn't that a step backwards, then? I see no reason for fee = pressure to=20 exist at the moment. All it's doing is turning away users for no = purpose:=20 mining isn't supported by fees, and the tiny fees we use right now = seem to=20 be good enough to stop penny=20 flooding.
 
Why not set the max size to be 20x the average size? Why 2x, = given you=20 just pointed out that'd result in blocks shrinking rather than=20 growing.

Twenty is = scary.
 
And two is a very neutral number: if 50% of = hashpower=20 want the max size to grow as fast as possible and 50% are dead-set = opposed to=20 any increase in max size, then half produce blocks 2 times as big, half = produce=20 empty blocks, and the max size doesn't change. If it was 20, then a = small=20 minority of miners could force a max size increase.  (if it is less = than 2,=20 then a minority of minors can force the block size down)
 
 
As for whether there "should" be fee pressure now or not: I have no = opinion, besides "we should make block propagation faster so there is no = technical reason for miners to produce tiny blocks." I don't think us = developers=20 should be deciding things like whether or not fees are too high, too = low,=20 .....
 
--
--
Gavin Andresen

-------------------------------------------------------------------------= -----

_______________________________________________
Bitcoin-development = mailing=20 list
Bitcoin-development@lists.sourceforge.net
https://lists.source= forge.net/lists/listinfo/bitcoin-development
= ------=_NextPart_000_006C_01D09932.93B6F540--