Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D89778FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 18:36:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A834249
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 18:36:34 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx101)
	with ESMTPSA (Nemesis) id 0MZPer-1Z7UAd3Ek9-00LH3q;
	Fri, 07 Aug 2015 20:36:31 +0200
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C6E85C60-E730-4D95-AF91-C8137EE738DD"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
Date: Fri, 7 Aug 2015 11:36:32 -0700
Message-Id: <17105AA2-F85D-4B81-8D2C-D71D9A1B5F3C@gmx.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:PgB4MkFBEmitSdg5QJSHg2N1VR/PBKkkG9yKdBWZCRM5/LYpZaZ
	2+4n5hlsGAoEJakkDuR2X8ULYIRB/Gw5ap2lYnPUqTDWpSKr5U/lbjKFEfE/m0Vvq7Rz20L
	DO09U/yxN86zT3hHmpsSX5C0nN5w/rmpc9KxhQE/ODNnTaJfa4N99LFqLfVOrlbwtOtPUdX
	bBG1dezpEdZ4bZq5LZFjQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nVjM8Ggt+VY=:YYGBacOqkuQ2ddMEplssTO
	AiIv7l/OrCekhMI0QSSVRopvw/3Es3tXXY9Ih87oqE2WU+5hMlWS5JxVJl+k7q+a3J0ga0O9X
	4LHDb0elx++wieqYiCSZOGiC55i5vyZksOI4kxdii7lqzX8A224u9JiAXP1TY8LUXgI4Mysqt
	Rav6KRWUnYnoM4p+XNBY5WKzBFwgG0I10QaSdS63W4mktIKNiD7wn9vrzhGbXRsL5iHeOVTZt
	Z+4LTfPlOTzfp3TVGLxQioEhNGEkH3l7BUyYJsfjLx2c3G1IzUo3lJh+iLbnPDD3gZMNaowIU
	SAxmE7QPQ4FCILz6WEhvgDgMl2lS6FGDxtpZjNI058PsijJSPN8Tpx5fd+wthRPRoBbyEV0vT
	UBRtpNhmjSNgxr36rR72IQhmlAb68jH1ZxVphLP76f0N1Pr+TTgOAfYnMlDH8zZxjwOfBEIb+
	h6l/kwaWuG/bWc9bP8Ja2vAHoM7Hybe99owXrZ/VNNFkybOc9jNZPRLDpsA34uKZ7KNaQPN7C
	fL5nyKz5eFjjwasgEBNA1DY4pHJh03hWhjZq+Pf5+YMh9pH74zQ8YwlHQAHdVw5iQR4O4yEbE
	zXuCYKvYKOgqqRItNwa0+QhD32Py2cVfDKEg/OW7b2HPtVYuxyiIw/4RCLEr2ewDa5ieQ6dF0
	TYotHGGQsQ1iY4imspjZDO2PsHy38ouHtLeuYG9glnb8ZOVZIg5KVZCYJ+/toUIkQ9vIA91Cz
	Wyk7WRAA8RCuLMpckgxVAjDeGKfBr6LTMrBXJA==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 18:36:34 -0000


--Apple-Mail=_C6E85C60-E730-4D95-AF91-C8137EE738DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> ...blocks are found at random intervals.
>=20
> Every once in a while the network will get lucky and we'll find six =
blocks in ten minutes. If you are deciding what transaction fee to put =
on your transaction, and you're willing to wait until that =
six-blocks-in-ten-minutes once-a-week event, submit your transaction =
with a low fee.
>=20
> All the higher-fee transactions waiting to be confirmed will get =
confirmed in the first five blocks and, if miners don't have any floor =
on the fee they'll accept (they will, but lets pretend they won't) then =
your very-low-fee transaction will get confirmed.
>=20
> In the limit, that logic becomes "wait an infinite amount of time, pay =
zero fee."
> ...
>=20
> Gavin Andresen

Yes, I see this as correct as well.  If demand for space within a =
particular block is elevated (e.g., when the network has not found a =
block for 30 minutes), the minimum fee density for inclusion will be =
greater than the minimum fee density when demand for space is low (e.g., =
when the network has found several blocks in quick succession, as Gavin =
pointed out).  Lower-fee paying transaction will just wait to be =
included at one of the network lulls where a bunch of blocks were found =
quickly in a row. =20

The feemarket.pdf paper ( =
https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf ) shows that =
this will always be the case so long as the block space supply curve =
(i.e., the cost in BTC/byte to supply additional space within a block =
[rho]) is a monotonically-increasing function of the block size (refer =
to Fig. 6 and Table 1).  The curve will satisfy this condition provided =
the propagation time for block solutions grows faster than log Q where Q =
is the size of the block.  Assuming that block solutions are propagated =
across physical channels, and that the quantity of pure information =
communicated per solution is proportional to the amount of information =
contained within the block, then the communication time will always grow =
asymptotically like O(Q) as per the Shannon-Hartely theorem, and the fee =
market will be healthy. =20

Best regards,
Peter


--Apple-Mail=_C6E85C60-E730-4D95-AF91-C8137EE738DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font =
color=3D"#000000">...</font>blocks are found at random =
intervals.</div><div><br></div><div>Every once in a while the network =
will get lucky and we'll find six blocks in ten minutes. If you are =
deciding what transaction fee to put on your transaction, and you're =
willing to wait until that six-blocks-in-ten-minutes once-a-week event, =
submit your transaction with a low fee.</div><div><br></div><div>All the =
higher-fee transactions waiting to be confirmed will get confirmed in =
the first five blocks and, if miners don't have any floor on the fee =
they'll accept (they will, but lets pretend they won't) then your =
very-low-fee transaction will get confirmed.</div><div><br></div><div>In =
the limit, that logic becomes "wait an infinite amount of time, pay zero =
fee."</div><div>...</div></div></div></div></blockquote><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_signature">Gavin =
Andresen</div></div></div></blockquote><div><br></div>Yes, I see this as =
correct as well. &nbsp;If demand for space within a particular block is =
elevated (e.g., when the network has not found a block for 30 minutes), =
the minimum fee density for inclusion will be greater than the minimum =
fee density when demand for space is low (e.g., when the network has =
found several blocks in quick succession, as Gavin pointed out). =
&nbsp;Lower-fee paying transaction will just wait to be included at one =
of the network lulls where a bunch of blocks were found quickly in a =
row. &nbsp;</div><div><br></div><div>The feemarket.pdf paper (&nbsp;<a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:=
//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a>&nbsp;) shows =
that this will always be the case so long as the block space supply =
curve (i.e., the cost in&nbsp;BTC/byte&nbsp;to supply additional space =
within a block [rho]) is a monotonically-increasing function of the =
block size (refer to Fig. 6 and Table 1). &nbsp;The curve will satisfy =
this condition provided the propagation time for block solutions grows =
faster than log Q where Q is the size of the block. &nbsp;Assuming =
that&nbsp;block solutions are propagated across physical channels, and =
that the quantity of pure information communicated per solution is =
proportional to the amount of information contained within the block, =
then the communication time will always grow asymptotically like O(Q) as =
per the Shannon-Hartely theorem, and the fee market will be healthy. =
&nbsp;</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div></body></html>=

--Apple-Mail=_C6E85C60-E730-4D95-AF91-C8137EE738DD--