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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
|
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 6CEAB486
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 22:15:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2CDC5235
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 22:15:44 +0000 (UTC)
Received: from [10.192.6.201] ([77.158.42.68]) by mail.gmx.com (mrgmx002) with
ESMTPSA (Nemesis) id 0MLfH9-1ZMpix3tHX-000uoe;
Thu, 06 Aug 2015 00:15:41 +0200
Content-Type: multipart/alternative;
boundary="Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com>
Date: Wed, 5 Aug 2015 15:15:43 -0700
Message-Id: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com>
References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com>
<1438640036.2828.0.camel@auspira.com>
<CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com>
<BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com>
To: Dave Hudson <dave@hashingit.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:NzdZejPgZlonnWG6GtnRCaJaAb7CByYOoP7nOhpQeJcdpUzjHIH
hmTSpCa95k+4IJGzA/7Aj1Wl/gXcCGenXPiIu0CmhoPuK6wx+St1893DC+ho0t7PBG5g0GN
HBzbPYOvIfi7NUAwLg/L5jeKfhHtc5DY6CiJGu5ht2UOnOdfuM/rcdkYvY/d1Mf28dz7+KV
W284nf7yYeZZDLvBY5snQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nIIefz3xfrs=:/1lYiiKM5HbAKgPoYjY8Ud
H+afoflPBR4xfVz8c68lyy4k7VUmKTGBr4v2Lqtau1nIzzaANt6cc3OxVaAItrLalcNZyFCVL
Zb9cPq27E9ga4zmVx/s0aUnoixlQxqj3/nhiIfFtPwD9ccsBhkqCet6yQhfA0a6TVoHpjZuL9
QIfJup5ijn6VDDmImi4F8ZxvxlB7BEn+lKjHWqVbTm3mEQxVvkKw/VVqnZVmzazs1A3dXaof8
s+81yJ24qqRiF5NMxF2W/qAuxEyTxuMDDFJgwzrtSPRhsC/YrjVJ7mLhJGsm+091evT01m1xA
2GeFBaeWcFB6WPuMPOtdyp7ClS6KmXI88bq9/DfOcfJb8ygzYgeNyLLfMOJi/qcwa2qX8X0P/
QPUtC5PoVraV7Qt27i1VjcmGIfC7+rSBwS+ESpc/kurEyTMdbRdZIteUTj+I+kqCAeXR7pds7
8s0uf2ynqcDqqXkGs7A5IYSsmVRmG11JFteaWJlE4P/LiptTomXVGkgy8EWbXFqWyfSk4UyKN
4RbW4snONYD7thGmEuthtPz3whLAEBDkcvmM66f8pb5s3iEOkiKGAt5I11sLX2mXc/9hpLGTV
KchjY4EgLmZBACjG5SjkrLm20O+FPOULIB9fn3wPMebEc2oh8bG0kEHRt2LKYKS5X+HX3YVYb
TbVYGhCgTpBqsLTsLgqTrNx9uVJOQFfcOdMirypvmqW+n3nh+349/5XWF0ChWYgQ5I3U=
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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] "A Transaction Fee Market Exists Without a Block
Size Limit"--new research paper suggests
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: Wed, 05 Aug 2015 22:15:45 -0000
--Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Hi Dave,
Thank you for the feedback regarding my paper. =20
> The paper is nicely done, but I'm concerned that there's a real =
problem with equation 4. The orphan rate is not just a function of time; =
it's also a function of the block maker's proportion of the network hash =
rate. Fundamentally a block maker (pool or aggregation of pools) does =
not orphan its own blocks.
With the benefit of hindsight, I think the paper would be stronger if it =
also analyzed how the model changes (or doesn't) if we assume zero =
propagation impedance for intra-miner communication, as you suggested =
(the "you don't orphan your own blocks" idea). Note that the paper did =
briefly discuss miner-dependent propagation times in the second =
paragraph of page 9 and in note 13. =20
> In a degenerate case a 100% pool has no orphaned blocks.
Agreed. In this case there's no information to communicate (since the =
miner has no peers) and so the Shannon-Hartley limit doesn't apply. My =
model makes no attempt to explain this case. =20
> Consider that a 1% miner must assume a greater risk from orphaning =
than, say, a pool with 25%, or worse 40% of the hash rate.
I'd like to explore this in more detail. Although a miner may not =
orphan his own block, by building on his own block he may now orphan two =
blocks in a row. At some point, his solution or solutions must be =
communicated to his peers. And if there's information about the =
transactions in his blocks to communicate, I think there's a cost =
associated with that. It's an interesting problem and I'd like to =
continue working on it. =20
> I suspect this may well change some of the conclusions as larger block =
makers will definitely be able to create larger blocks than their =
smaller counterparts.
It will be interesting to see. I suspect that the main result that "a =
healthy fee market exists" will still hold (assuming of course that a =
single miner with >50% of the hash power isn't acting maliciously). =
Whether miners with larger value of h/H have a profit advantage, I'm not =
sure (but that was outside the scope of the paper anyways). =20
Best regards,
Peter
>> On 3 Aug 2015, at 23:40, Peter R via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Dear Bitcoin-Dev Mailing list,
>>=20
>> I=92d like to share a research paper I=92ve recently completed titled =
=93A Transaction Fee Market Exists Without a Block Size Limit.=94 In =
addition to presenting some useful charts such as the cost to produce =
large spam blocks, I think the paper convincingly demonstrates that, due =
to the orphaning cost, a block size limit is not necessary to ensure a =
functioning fee market. =20
>>=20
>> The paper does not argue that a block size limit is unnecessary in =
general, and in fact brings up questions related to mining cartels and =
the size of the UTXO set. =20
>>=20
>> It can be downloaded in PDF format here:
>>=20
>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>>=20
>> Or viewed with a web-browser here:
>>=20
>> =
https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Witho=
ut-a-Block-Size-Limit
>>=20
>> Abstract. This paper shows how a rational Bitcoin miner should =
select transactions from his node=92s mempool, when creating a new =
block, in order to maximize his profit in the absence of a block size =
limit. To show this, the paper introduces the block space supply curve =
and the mempool demand curve. The former describes the cost for a miner =
to supply block space by accounting for orphaning risk. The latter =
represents the fees offered by the transactions in mempool, and is =
expressed versus the minimum block size required to claim a given =
portion of the fees. The paper explains how the supply and demand =
curves from classical economics are related to the derivatives of these =
two curves, and proves that producing the quantity of block space =
indicated by their intersection point maximizes the miner=92s profit. =
The paper then shows that an unhealthy fee market=97where miners are =
incentivized to produce arbitrarily large blocks=97cannot exist since it =
requires communicating information at an arbitrarily fast rate. The =
paper concludes by considering the conditions under which a rational =
miner would produce big, small or empty blocks, and by estimating the =
cost of a spam attack. =20
>>=20
>> Best regards,
>> Peter
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Hi Dave,</div><div><br></div><div>Thank you for the feedback =
regarding my paper. </div><div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><meta =
http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">The paper is nicely done, but I'm concerned =
that there's a real problem with equation 4. The orphan rate is not just =
a function of time; it's also a function of the block maker's proportion =
of the network hash rate. Fundamentally a block maker (pool or =
aggregation of pools) does not orphan its own =
blocks.</div></div></blockquote><div><br></div><div>With the benefit of =
hindsight, I think the paper would be stronger if it also analyzed how =
the model changes (or doesn't) if we assume zero propagation impedance =
for intra-miner communication, as you suggested (the "you don't orphan =
your own blocks" idea). Note that the paper did briefly =
discuss miner-dependent propagation times in the second paragraph of =
page 9 and in note 13. </div><div><br></div><div><blockquote =
type=3D"cite"><div class=3D"" style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div =
class=3D"">In a degenerate case a 100% pool has no orphaned blocks. =
</div></div></blockquote><div><br></div><div>Agreed. In this case =
there's no information to communicate (since the miner has no peers) and =
so the Shannon-Hartley limit doesn't apply. My model makes no =
attempt to explain this case. </div><br><blockquote =
type=3D"cite"><div class=3D"" style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div =
class=3D"">Consider that a 1% miner must assume a greater risk from =
orphaning than, say, a pool with 25%, or worse 40% of the hash =
rate.</div></div></blockquote><br></div><div>I'd like to explore this in =
more detail. Although a miner may not orphan his own block, by =
building on his own block he may now orphan two blocks in a row. =
At some point, his solution or solutions must be communicated to =
his peers. And if there's information about the transactions in =
his blocks to communicate, I think there's a cost associated with that. =
It's an interesting problem and I'd like to continue working on =
it. </div><div><br></div><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><div class=3D"">I =
suspect this may well change some of the conclusions as larger block =
makers will definitely be able to create larger blocks than their =
smaller counterparts.</div></div></blockquote><div><br></div><div>It =
will be interesting to see. I suspect that the main result that "a =
healthy fee market exists" will still hold (assuming of course that a =
single miner with >50% of the hash power isn't acting maliciously). =
Whether miners with larger value of h/H have a profit advantage, =
I'm not sure (but that was outside the scope of the paper anyways). =
</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><div><br></div><div><br></div=
><blockquote type=3D"cite"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
3 Aug 2015, at 23:40, Peter R via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; " class=3D""><div class=3D"">Dear =
Bitcoin-Dev Mailing list,</div><div class=3D""><br class=3D""></div><div =
class=3D"">I=92d like to share a research paper I=92ve recently =
completed titled =93A Transaction Fee Market Exists Without a Block Size =
Limit.=94 In addition to presenting some useful charts such as the =
cost to produce large spam blocks, I think the paper convincingly =
demonstrates that, due to the orphaning cost, a block size limit is not =
necessary to ensure a functioning fee market. </div><div =
class=3D""><br class=3D""></div><div class=3D"">The paper does not argue =
that a block size limit is unnecessary in general, and in fact brings up =
questions related to mining cartels and the size of the UTXO set. =
</div><div class=3D""><br class=3D""></div><div class=3D"">It =
can be downloaded in PDF format here:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf" =
class=3D"">https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a><=
/div><div class=3D""><br class=3D""></div><div class=3D"">Or viewed with =
a web-browser here:</div><div class=3D""><br class=3D""></div><div =
class=3D""><a =
href=3D"https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exis=
ts-Without-a-Block-Size-Limit" =
class=3D"">https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-E=
xists-Without-a-Block-Size-Limit</a></div><div class=3D""><br =
class=3D""></div><div class=3D""><b class=3D"">Abstract. </b>This =
paper shows how a rational Bitcoin miner should select transactions from =
his node=92s mempool, when creating a new block, in order to maximize =
his profit in the absence of a block size limit. To show this, the paper =
introduces the block space supply curve and the mempool demand curve. =
The former describes the cost for a miner to supply block space by =
accounting for orphaning risk. The latter represents the fees =
offered by the transactions in mempool, and is expressed versus the =
minimum block size required to claim a given portion of the fees. =
The paper explains how the supply and demand curves from classical =
economics are related to the derivatives of these two curves, and proves =
that producing the quantity of block space indicated by their =
intersection point maximizes the miner=92s profit. The paper then =
shows that an unhealthy fee market=97where miners are incentivized to =
produce arbitrarily large blocks=97cannot exist since it requires =
communicating information at an arbitrarily fast rate. The paper =
concludes by considering the conditions under which a rational miner =
would produce big, small or empty blocks, and by estimating the cost of =
a spam attack. </div><div class=3D""><br class=3D""></div><div =
class=3D"">Best regards,</div><div =
class=3D"">Peter</div></div>______________________________________________=
_<br class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">ht=
tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br =
class=3D""></div></blockquote></div><br =
class=3D""></div></blockquote></div><br></body></html>=
--Apple-Mail=_067B9CA0-8438-495F-88B4-D7031AF163B5--
|
