From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D89778FC for ; 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 ; 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 In-Reply-To: Date: Fri, 7 Aug 2015 11:36:32 -0700 Message-Id: <17105AA2-F85D-4B81-8D2C-D71D9A1B5F3C@gmx.com> References: To: Gavin Andresen 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
...blocks are found at random = intervals.

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.

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.

In = the limit, that logic becomes "wait an infinite amount of time, pay zero = fee."
...

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.  

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. =  

Best = regards,
Peter

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