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
|
Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C90351BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 20:01:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com
[209.85.217.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EFF8319D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 20:01:20 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so50884241lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 13:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=12oqZgGGdxXmElm+X08IwePNCnIO8uPdbVffGLJ3MUs=;
b=pDpIVh8VZmB0k2ex7s1LLRSU9hG+sclEttmn0MXHP/AScs7igcvfh7KGS2Hjor++CP
SYZsdzXKPwlmhyn/DcDaVTGYOOke36nItSfiNeZxGWmG8Ma/9IfwLY8gOnyFp0nDTZjG
O6scXOrZha7EvmILuKonph23MkXo7DlRwUR8MemNiyRRz/kRi71RvmEkjEeZ2x8wSLKa
OHG+vKqR/VXNsHr9lj+IBXqpN9zv6zikYpVGtRyJMZ8LNFIjTfcl71LNlA8MREzrm9wv
d8HP/MKyMfX0ECzvQSgdmc8CqSOUMipusbEFviznTHqHccEWpOdWV8/bJC0rgdc1/Ll0
a0sA==
X-Received: by 10.112.199.5 with SMTP id jg5mr8922296lbc.57.1440964879452;
Sun, 30 Aug 2015 13:01:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.143.229 with HTTP; Sun, 30 Aug 2015 13:01:00 -0700 (PDT)
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Sun, 30 Aug 2015 22:01:00 +0200
Message-ID: <CAEgR2PE35K6kt1sZ0iDu2Y9vv+6+Omgg_n4n3gtMggYuE3YD-g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c2432cc6113d051e8cc7a9
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
HTML_OBFUSCATE_05_10,
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
Subject: [bitcoin-dev] ERRATA CORRIGE + Short Theorem
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: Sun, 30 Aug 2015 20:01:21 -0000
--001a11c2432cc6113d051e8cc7a9
Content-Type: text/plain; charset=UTF-8
Since my longer post seems to be caught in moderator purgatory I will
rehash its results into this much smaller message. I apologize for the
spamming.
I present a theorem whose thesis is obvious to many.
*THESIS: All hashrates* *h' > h generate a revenue per unit of hash v' >
v. *
Let us absurdly[1] assume that an optimal hashrate *h* exists where the
average revenue for each hash in service is maximized. This will result
from perpetually mining blocks of size *q,* is *v. *All larger hashrates *h'
> h* will generate an average revenue per hash *v' < v*(effectively the
conclusion of my paper) due to the higher orphan risk carried from having
to mine blocks of size *q' > q*. Leading from Peter's model and my
analysis, the origin of this balance lies in the fact that larger miners
must somehow be forced to mine larger blocks which in turn carry a larger
orphan risk.
What happens if a large miner *h'* chooses not to mine his optimal block
size *q' *in favor of a seemingly "sub-optimal" block size* q*?
Since he mines a block of identical size as the smaller miner, they will
both carry identical orphan risks[2], and win identical
amounts*R+M(q)* whenever
they successfully mine a block. Since the larger miner can statistically
expect to win *h'/h* more blocks than the smaller miner, they will each
earn an identical revenue per unit of hash *R+M(q)/h*.
This however directly contradicts the assumption that an optimal hashrate
exists beyond which the revenue per unit of hash *v' < v*if *h' > h. *
*Q.E.D *
This theorem in turn implies the following corollary:
*COROLLARY: **The marginal profit curve is a monotonically increasing of
miner hashrate.*
This simple theorem, suggested implicitly by Gmaxwell disproves any and all
conclusions of my work. Most importantly, centralization pressures will
always be present.
Furthermore,
[1] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
[2] Orphan risks will actually favor the larger hashrate miner leading to
greater revenues per unit of hash.
I thank the dev-list for its valuable time and exchange on the subject
matter. I stand by for any further comments and questions.
--001a11c2432cc6113d051e8cc7a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Since my longer post seems to be caught in moderator purga=
tory I will rehash its results into this much smaller message. I apologize =
for the spamming.<br><br>I present a theorem whose thesis is obvious to man=
y.<br><br><div style=3D"font-size:12.8000001907349px"><b>THESIS: All hashra=
tes</b>=C2=A0<span style=3D"font-size:12.8000001907349px"><b><i>h' >=
h=C2=A0</i>generate a revenue per unit of hash<i>=C2=A0v' > v.=C2=
=A0</i></b></span></div><div style=3D"font-size:12.8000001907349px"><br></d=
iv><div style=3D"font-size:12.8000001907349px">Let us absurdly[1] assume th=
at an optimal hashrate=C2=A0<i><b>h</b></i><b><i>=C2=A0</i></b>exists where=
the average revenue for each hash in service is maximized. This will resul=
t from perpetually mining blocks of size=C2=A0<i><b>q,</b></i>=C2=A0is=C2=
=A0<i><b>v.=C2=A0</b></i>All larger hashrates=C2=A0<i><b>h' > h</b><=
/i>=C2=A0will=C2=A0<span style=3D"font-size:12.8000001907349px">generate</s=
pan><span style=3D"font-size:12.8000001907349px">=C2=A0an average revenue p=
er hash=C2=A0</span><i style=3D"font-size:12.8000001907349px;font-weight:bo=
ld">v' < v</i><span style=3D"font-size:12.8000001907349px">(effectiv=
ely the conclusion of my paper) due to the higher orphan risk carried from =
having to mine blocks of size=C2=A0</span><i style=3D"font-size:12.80000019=
07349px"><b>q' > q</b></i><span style=3D"font-size:12.8000001907349p=
x">. Leading from Peter's model and my analysis, the origin of this bal=
ance lies in the fact that larger miners must somehow be forced to mine lar=
ger blocks which in turn carry a larger orphan risk.=C2=A0</span></div><div=
style=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:1=
2.8000001907349px">What happens if a large miner=C2=A0<i><b>h'</b></i>=
=C2=A0chooses not to mine his optimal block size=C2=A0<i style=3D"font-weig=
ht:bold">q'=C2=A0</i>in favor of a seemingly "sub-optimal" bl=
ock size<i style=3D"font-weight:bold">=C2=A0q</i>?</div><div class=3D"gmail=
_extra" style=3D"font-size:12.8000001907349px">Since he mines a block of id=
entical size as the smaller miner, they will both carry identical orphan ri=
sks[2], and win identical amounts<i><b>R+M(q)</b></i>=C2=A0whenever they su=
ccessfully mine a block. Since the larger miner can statistically expect to=
win=C2=A0<i><b>h'/h</b></i>=C2=A0more blocks than the smaller miner, t=
hey will each earn an identical revenue per unit of hash=C2=A0<i><b>R+M(q)/=
h</b></i>.=C2=A0</div><div class=3D"gmail_extra" style=3D"font-size:12.8000=
001907349px"><br></div><div class=3D"gmail_extra" style=3D"font-size:12.800=
0001907349px">This however directly contradicts the assumption that an opti=
mal hashrate exists beyond which the revenue per unit of hash=C2=A0<i style=
=3D"font-size:12.8000001907349px;font-weight:bold">v' < v</i><span s=
tyle=3D"font-size:12.8000001907349px">if</span><i style=3D"font-size:12.800=
0001907349px;font-weight:bold">=C2=A0</i><span style=3D"font-size:12.800000=
1907349px">=C2=A0</span><i style=3D"font-size:12.8000001907349px"><b>h'=
> h.=C2=A0</b></i></div><div class=3D"gmail_extra" style=3D"font-size:1=
2.8000001907349px"><i style=3D"font-size:12.8000001907349px"><b>Q.E.D=C2=A0=
</b></i></div><div class=3D"gmail_extra" style=3D"font-size:12.800000190734=
9px"><i style=3D"font-size:12.8000001907349px"><b><br></b></i></div><div cl=
ass=3D"gmail_extra" style=3D"font-size:12.8000001907349px"><span style=3D"f=
ont-size:12.8000001907349px">This theorem in turn implies the following cor=
ollary:</span></div><div class=3D"gmail_extra" style=3D"font-size:12.800000=
1907349px"><i style=3D"font-size:12.8000001907349px"><b><br></b></i></div><=
div class=3D"gmail_extra" style=3D"font-size:12.8000001907349px"><span styl=
e=3D"font-size:12.8000001907349px"><b>COROLLARY:=C2=A0</b></span><span styl=
e=3D"font-size:12.8000001907349px"><b>The marginal profit curve is a monoto=
nically increasing of miner hashrate.</b></span></div><div class=3D"gmail_e=
xtra" style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12.80=
00001907349px"><b><br></b></span></div><div class=3D"gmail_extra" style=3D"=
font-size:12.8000001907349px"><span style=3D"font-size:12.8000001907349px">=
This simple theorem, suggested implicitly by Gmaxwell disproves any and all=
conclusions of my work. Most importantly, centralization pressures will al=
ways be present.=C2=A0</span></div><div class=3D"gmail_extra" style=3D"font=
-size:12.8000001907349px"><span style=3D"font-size:12.8000001907349px"><br>=
</span></div><div class=3D"gmail_extra" style=3D"font-size:12.8000001907349=
px"><span style=3D"font-size:12.8000001907349px">Furthermore,=C2=A0</span><=
/div><div class=3D"gmail_extra" style=3D"font-size:12.8000001907349px"><spa=
n style=3D"font-size:12.8000001907349px"><b><br></b></span></div><div class=
=3D"gmail_extra" style=3D"font-size:12.8000001907349px">[1]=C2=A0<a href=3D=
"https://en.wikipedia.org/wiki/Reductio_ad_absurdum" target=3D"_blank">http=
s://en.wikipedia.org/wiki/Reductio_ad_absurdum</a></div><div class=3D"gmail=
_extra" style=3D"font-size:12.8000001907349px">[2] Orphan risks will actual=
ly favor the larger hashrate miner leading to greater revenues per unit of =
hash.</div><div class=3D"gmail_extra" style=3D"font-size:12.8000001907349px=
"><br></div><div class=3D"gmail_extra" style=3D"font-size:12.8000001907349p=
x">I thank the dev-list for its valuable time and exchange on the subject m=
atter. I stand by for any further comments and questions.</div><div><div cl=
ass=3D"gmail_signature"><div dir=3D"ltr"><br></div></div></div>
</div>
--001a11c2432cc6113d051e8cc7a9--
|
