1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
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--
|
