diff options
| author | Peter R <peter_r@gmx.com> | 2015-08-07 11:36:32 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-07 18:36:34 +0000 |
| commit | 9671d4dd83e6868b1f6d517de4ba2e035263b628 (patch) | |
| tree | 6966f0796e8b8eeda8471655463d995cecb0db29 | |
| parent | aedaf09a8f5590e0ced250abc492b48bbf3ad150 (diff) | |
| download | pi-bitcoindev-9671d4dd83e6868b1f6d517de4ba2e035263b628.tar.gz pi-bitcoindev-9671d4dd83e6868b1f6d517de4ba2e035263b628.zip | |
Re: [bitcoin-dev] Fees and the block-finding process
| -rw-r--r-- | c1/bbc8e0d60e41eac3a24b02bf973ff2a6bbee8b | 162 |
1 files changed, 162 insertions, 0 deletions
diff --git a/c1/bbc8e0d60e41eac3a24b02bf973ff2a6bbee8b b/c1/bbc8e0d60e41eac3a24b02bf973ff2a6bbee8b new file mode 100644 index 000000000..b304c02d8 --- /dev/null +++ b/c1/bbc8e0d60e41eac3a24b02bf973ff2a6bbee8b @@ -0,0 +1,162 @@ +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. 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. </div><div><br></div><div>The feemarket.pdf paper ( <a = +href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:= +//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a> ) 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. = + </div><div><br></div><div>Best = +regards,</div><div>Peter</div><div><br></div></body></html>= + +--Apple-Mail=_C6E85C60-E730-4D95-AF91-C8137EE738DD-- + |