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 1YraOD-0000Oa-7C for bitcoin-development@lists.sourceforge.net; Sun, 10 May 2015 23:12:05 +0000 X-ACL-Warn: Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YraOC-0006jF-3V for bitcoin-development@lists.sourceforge.net; Sun, 10 May 2015 23:12:05 +0000 Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0A4FBFB8A7; Mon, 11 May 2015 01:11:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ECRdSjRmMxJl; Mon, 11 May 2015 01:11:56 +0200 (CEST) X-Originating-IP: 92.229.161.198 Received: from [192.168.1.3] (x5ce5a1c6.dyn.telefonica.de [92.229.161.198]) (Authenticated sender: thomasv@electrum.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 57D86FB88B; Mon, 11 May 2015 01:11:56 +0200 (CEST) Message-ID: <554FE5BB.3040201@electrum.org> Date: Mon, 11 May 2015 01:11:55 +0200 From: Thomas Voegtlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark Friedenbach References: <16096345.A1MpJQQkRW@crushinator> <554FD237.2020009@electrum.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YraOC-0006jF-3V Cc: Bitcoin Development 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: Sun, 10 May 2015 23:12:05 -0000 Le 11/05/2015 00:31, Mark Friedenbach a =C3=A9crit : > I'm on my phone today so I'm somewhat constrained in my reply, but the = key > takeaway is that the proposal is a mechanism for miners to trade subsid= y > for the increased fees of a larger block. Necessarily it only makes sen= se > to do so when the marginal fee per KB exceeds the subsidy fee per KB. I= t > correspondingly makes sense to use a smaller block size if fees are les= s > than subsidy, but note that fees are not uniform and as the block shrin= ks > the marginal fee rate goes up.. >=20 Oh I see, you expect the sign of the dE/dx to change depending on whether fees exceed the subsidy. This is possible, but instead of the linear identity, you have to increase the block size twice as fast as the difficulty. In that case we would get (using the notations of my previous email): D' =3D D(1+x) F' =3D F(1+2x) and thus: E' - E =3D x/(1+x)P(F-S) The presence of the (F-S) factor means that the sign reversal occurs when fees exceed subsidy. > Limits on both the relative and absolute amount a miner can trade subsi= dy > for block size prevent incentive edge cases as well as prevent a sharp > shock to the current fee-poor economy (by disallowing adjustment below = 1MB). >=20 > Also the identity transform was used only for didactic purposes. I full= y > expect there to be other, more interesting functions to use.