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
|
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 BDE7B1275
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 23:17:04 +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 D2BBD15F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 23:17:03 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx102)
with ESMTPSA (Nemesis) id 0LsOsW-1YYavr3U2C-011yWR;
Sun, 30 Aug 2015 01:17:00 +0200
Content-Type: multipart/alternative;
boundary="Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <55E21F2E.9000308@mattcorallo.com>
Date: Sat, 29 Aug 2015 16:17:12 -0700
Message-Id: <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
<55E21F2E.9000308@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:Ij9wnPePw8gqtLDuPirLtX2Bstx+bWc+nCeIH1FVPED49r+tgjT
AmeUlFS3dvZoNIhVe9EB2lL12BGxxa8tZgIbX1L++53vwuc90sZHLkamTlviWnnSl0UbHZl
bedGtIKu32jCONOQehujgaIGfvm5qLK4fe+t7GQv+0A0KanCCGKmsYCLB0VinxSD1Qs2Aoa
kouZ2zJHx46uky1fhWe7w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UxBDs5JGfBs=:P0txK9IoD1tXwx1UA+ZN5i
lc2CupxlRcLVBFw17TpOo7HC7r8AWIXZLv4c6GiLlR6Rqn4PMy3d+j31ddNsEWP2Tx0sVUz43
85f42aSCOJ+XTYPmiZfqeJeOuqgb2WX2CBtr/2NJ8xC+oZjtTh8IeoWEZziAoWBhASb5okFca
XVKNoDmZbHUlcYZtrxP3EL5ww0+xGzRrlslnNnIyrZjIc9VOJLe9Gr8lFSWTQLtplPRgKpxcW
ePa5pzGP1FXzpR8Yp0vvg4O4RwEKKSQiCIiTYZCZwP1thLVgDBc8Dz+knhRnGzyPtR4m3jv0d
2EVd8YLaMS26j5sEgkkh8lGTERoN9uq0M3RPZtqDax7ucfHdiWCb1jFAgaAwGiCjpp37DvIFu
UksXiSg6QLlV2x9ko+eQYnY2StBwvWO9Bn65YSSsJOfpTjLe6r0foygO/E3kfJf9FvMVd+iJS
mN0EONLp+bmoENpcrxy1so2r+BEYSd6bgLbtDN0pvE3l1NSRl5ApKr1M1zTxVSY9vM/iWQCha
hOowQ00F67I5SJ1Bp90fdo+glmj/I73WGmMz0wjR6fT48hzDuMt5yNRZLZVIog1E2o3onYFbK
92XaW5bQFYixGMq7Ix9BqFBXqtsS0jYmW1KRGjgYqp2tTX1uhuQ2S44NGsDRtozpGEHpbw5lP
iegBGeIuow2A7HamKHzRiU1Jw/O9ymipTRm8xZuhL0IWcH3jyTX2U7XKWgdrjVTLJJoOmPG8n
a09oQ8lMunYoXazg6/MIodG9GKDh5AegufA3sg==
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@lists.linuxfoundation.org,
Daniele Pinna <daniele.pinna@gmail.com>
Subject: Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped
Block Size Fee Markets
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: Sat, 29 Aug 2015 23:17:04 -0000
--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hello Matt and Daniele,
> this seems to ignore the effects of transaction validation caches and =
block
> compression protocols.=20
The effect of block compression protocols is included. This is what I =
call the "coding gain" and use the Greek letter "gamma" to represent.=20
As long as the block solution announcements contain information (i.e., =
Shannon Entropy) about the transactions included in a block, then the =
fee market will be "healthy" according to the definitions given in the =
linked paper (see below). This is the case right now, this is the case =
with your relay network, and this would be the case using any =
implementation of IBLTs that I can imagine, so long as miners can still =
construct blocks according to their own volition. The "healthy fee =
market" result follows from the Shannon-Hartley theorem; the SH-theorem =
describes the maximum rate at which information (Shannon Entropy) can be =
transmitted over a physical communication channel. =20
https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
I've exchanged emails with Greg Maxwell about (what IMO is) an academic =
scenario where the block solutions announcements contain no information =
at all about the transactions included in the blocks. Although the fee =
market would not be healthy in such a scenario, it is my feeling that =
this also requires miners to relinquish their ability to construct =
blocks according to their own volition (i.e., the system would already =
be centralized). I look forward to a white paper demonstrating =
otherwise!
Best regards,
Peter
On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I believe it was pointed out previously in the discussion of the Peter =
R
> paper, but I'll repeat it here so that its visible - this seems to
> ignore the effects of transaction validation caches and block
> compression protocols. Many large miners already have their own =
network
> to relay blocks around the globe with only a few bytes on the wire at
> block-time, and there is also the bitcoinrelaynetwork.org network, =
which
> does the same for smaller miners, albeit with slightly less =
efficiency.
> Also, transaction validation time upon receiving a block can be rather
> easily made negligible (ie the only validation time you should have is
> the DB modify-utxo-set time). Thus, the increased orphan risk for
> including a transaction can be reduced to a very, very tiny amount,
> making the optimal blocksize, essentially, including everything that
> you're confident is in the mempool of other reasonably large miners.
>=20
> Matt
>=20
> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
>> I'd like to submit this paper to the dev-list which analyzes how =
miner
>> advantages scale with network and mempool properties in a scenario of
>> uncapped block sizes. The work proceeds, in a sense, from where Peter
>> R's work left off correcting a mistake and addressing the critiques =
made
>> by the community to his work.
>>=20
>> The main result of the work is a detailed analysis of mining =
advantages
>> (defined as the added profit per unit of hash) as a function of miner
>> hashrate. In it, I show how large block subsidies (or better, low
>> mempool fees-to-subsidy ratios) incentivize the pooling of large
>> hashrates due to the steady increasing of marginal profits as =
hashrates
>> grow.=20
>>=20
>> The paper also shows that part of the large advantage the large =
miners
>> have today is due to there being a barrier to entry into a
>> high-efficiency mining class which has access to expected profits an
>> order of magnitude larger than everyone else. As block subsidies
>> decrease, this high-efficiency class is expected to vanish leading to =
a
>> marginal profit structure which decreases as a function of hashrate.
>>=20
>> This work has vacuumed my entire life for the past two weeks leading =
me
>> to lag behind on a lot of work. I apologize for typos which I may not
>> have seen. I stand by for any comments the community may have and =
look
>> forward to reigniting consideration of a block size scaling proposal
>> (BIP101) which, due to the XT fork drama, I believe has been placed
>> hastily and undeservedly on the chopping block.
>>=20
>> =
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-=
Uncapped-Block-Size-Fee-Markets
>>=20
>>=20
>> Regards,
>> Daniele
>>=20
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E
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>Hello Matt and Daniele,</div><br><blockquote =
type=3D"cite"> this seems to ignore the effects of transaction =
validation caches and <b>block<br>compression =
protocols. </b></blockquote><div><br></div><div>The effect of block =
compression protocols is included. This is what I call the "coding =
gain" and use the Greek letter "gamma" to =
represent. </div><div><br></div><div>As long as the block solution =
announcements contain information (i.e., Shannon Entropy) about the =
transactions included in a block, then the fee market will be "healthy" =
according to the definitions given in the linked paper (see below). =
This is the case right now, this is the case with your relay =
network, and this would be the case using any implementation of IBLTs =
that I can imagine, so long as miners can still construct blocks =
according to their own volition. The "healthy fee market" result =
follows from the Shannon-Hartley theorem; the SH-theorem describes the =
maximum rate at which information (Shannon Entropy) can be transmitted =
over a physical communication channel. =
</div><div><br></div><div> <a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:=
//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a></div><div><br></d=
iv><div>I've exchanged emails with Greg Maxwell about (what IMO is) an =
academic scenario where the block solutions announcements contain <b>no =
information at all</b> about the transactions included in the blocks. =
Although the fee market would not be healthy in such a scenario, =
it is my feeling that this also requires miners to relinquish their =
ability to construct blocks according to their own volition (i.e., the =
system would already be centralized). I look forward to a white =
paper demonstrating otherwise!</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><div><br></div><br><div><div>=
On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">I believe =
it was pointed out previously in the discussion of the Peter R<br>paper, =
but I'll repeat it here so that its visible - this seems to<br>ignore =
the effects of transaction validation caches and block<br>compression =
protocols. Many large miners already have their own network<br>to relay =
blocks around the globe with only a few bytes on the wire =
at<br>block-time, and there is also the <a =
href=3D"http://bitcoinrelaynetwork.org">bitcoinrelaynetwork.org</a> =
network, which<br>does the same for smaller miners, albeit with slightly =
less efficiency.<br>Also, transaction validation time upon receiving a =
block can be rather<br>easily made negligible (ie the only validation =
time you should have is<br>the DB modify-utxo-set time). Thus, the =
increased orphan risk for<br>including a transaction can be reduced to a =
very, very tiny amount,<br>making the optimal blocksize, essentially, =
including everything that<br>you're confident is in the mempool of other =
reasonably large miners.<br><br>Matt<br><br>On 08/29/15 16:43, Daniele =
Pinna via bitcoin-dev wrote:<br><blockquote type=3D"cite">I'd like to =
submit this paper to the dev-list which analyzes how miner<br>advantages =
scale with network and mempool properties in a scenario of<br>uncapped =
block sizes. The work proceeds, in a sense, from where Peter<br>R's work =
left off correcting a mistake and addressing the critiques made<br>by =
the community to his work.<br><br>The main result of the work is a =
detailed analysis of mining advantages<br>(defined as the added profit =
per unit of hash) as a function of miner<br>hashrate. In it, I show how =
large block subsidies (or better, low<br>mempool fees-to-subsidy ratios) =
incentivize the pooling of large<br>hashrates due to the steady =
increasing of marginal profits as hashrates<br>grow. <br><br>The paper =
also shows that part of the large advantage the large miners<br>have =
today is due to there being a barrier to entry into a<br>high-efficiency =
mining class which has access to expected profits an<br>order of =
magnitude larger than everyone else. As block subsidies<br>decrease, =
this high-efficiency class is expected to vanish leading to =
a<br>marginal profit structure which decreases as a function of =
hashrate.<br><br>This work has vacuumed my entire life for the past two =
weeks leading me<br>to lag behind on a lot of work. I apologize for =
typos which I may not<br>have seen. I stand by for any comments the =
community may have and look<br>forward to reigniting consideration of a =
block size scaling proposal<br>(BIP101) which, due to the XT fork drama, =
I believe has been placed<br>hastily and undeservedly on the chopping =
block.<br><br><a =
href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advant=
ages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.com/doc/276849=
939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets</=
a><br><br><br>Regards,<br>Daniele<br><br><br>_____________________________=
__________________<br>bitcoin-dev mailing =
list<br>bitcoin-dev@lists.linuxfoundation.org<br>https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev<br><br></blockquote>________________=
_______________________________<br>bitcoin-dev mailing list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br></blockquote></div><br></body></html>=
--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E--
|
