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
|
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 A92F3146D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 08:53:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E489F12D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 08:53:07 +0000 (UTC)
Received: by lbvd4 with SMTP id d4so38544236lbv.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 01:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=2apURqucK9M63DGypn2oNQxhYzG+cPSFA98vWQIgplE=;
b=aqvuRVkta9VWoTI33l/cEdh8GyA/YFK/hDRB/iwjCI4LvKrujeB/MDz5I7fOLTn15a
QH6ecLRhDN5GqlzilxUCkbZG0VLerG7M+aYWIsRFhAh2Rx9AwDykU34AuGojaEGUxfuD
s8Nsywyu2fwLAk1e2ORyfFyBD99ScqE6UmF0hb+877Q7etPW3LGLAZerboC5bQv2bckv
CSOKNhaEEKvQVezaXNpi5yhXAGmRgTNBtqjMToFYfox9Qcrnxb3SKSUzkfdTUaeShtQx
5+b4Vn5iSrGFQnmHxGK/iFRZlu7+uxvvbkjpPinOqJ6LqUmO0tZ+CVJ1N4iZs33iDixy
9xbQ==
X-Received: by 10.152.23.167 with SMTP id n7mr12586458laf.108.1441097586011;
Tue, 01 Sep 2015 01:53:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.143.229 with HTTP; Tue, 1 Sep 2015 01:52:46 -0700 (PDT)
In-Reply-To: <7E54183F-DDBD-4EFB-828B-841350A80E33@gmx.com>
References: <CAEgR2PE35K6kt1sZ0iDu2Y9vv+6+Omgg_n4n3gtMggYuE3YD-g@mail.gmail.com>
<20150901075613.GD17380@muck>
<7E54183F-DDBD-4EFB-828B-841350A80E33@gmx.com>
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Tue, 1 Sep 2015 10:52:46 +0200
Message-ID: <CAEgR2PFcPgUmfBNhqXBQdPD_O_24sMDmsX23+qsuzsU92KZS6A@mail.gmail.com>
To: Peter R <peter_r@gmx.com>
Content-Type: multipart/alternative; boundary=089e0160a5e6b3737c051eabad44
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
Subject: Re: [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: Tue, 01 Sep 2015 08:53:08 -0000
--089e0160a5e6b3737c051eabad44
Content-Type: text/plain; charset=UTF-8
My paper did show that the advantage decreased with the block reward.
However, in that limit, it also seemed to imply that a network state would
appear where the revenue per unit hash decreased with increasing hashrate
which should be impossible as just discussed.
In a followup email, I showed how the origin of this effect stems from the
orphaning factor used which doesn't preserve the full network revenue per
unit block. This led me to correct my assertions by pointing out that our
miner profit equations seemed to be just lower bounds to the miner's true
expected profit. As such, just because the *lower bound* on the revenue per
unit hash advantage decreases with the block reward, this doesn't
necessarily imply that the *real* revenue per unit hash advantage does also.
I suspect that the orphaning factor used, independently of the specific
form of the block relay time, is incorrect or incomplete as stated.
Best,
Daniele
Daniele Pinna, Ph.D
On Tue, Sep 1, 2015 at 10:06 AM, Peter R <peter_r@gmx.com> wrote:
> On 2015-09-01, at 12:56 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote
>
>
> FWIW I did a quick math proof along those lines awhile back too using
> some basic first-year math, again proving that larger miners earn more
> money per unit hashing power:
>
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03272.html
>
>
> I don't believe anyone is arguing otherwise. Miners with a larger
> fraction of the network hash rate, *h*/*H*, have a theoretical advantage,
> all other variables in the miner's profitability equation held constant.
>
> Dpinna originally claimed (unless I'm mistaken) that his paper showed that
> this advantage *decreased* as the block reward diminished or as the total
> fees increased. This didn't seem unreasonable to me, although I never
> checked the math.
>
> Best regards,
> Peter
>
>
>
>
>
--089e0160a5e6b3737c051eabad44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My paper did show that the advantage decreased with the bl=
ock reward. However, in that limit, it also seemed to imply that a network =
state would appear where the revenue per unit hash decreased with increasin=
g hashrate which should be impossible as just discussed.<br><br>In a follow=
up email, I showed how the origin of this effect stems from the orphaning f=
actor used which doesn't preserve the full network revenue per unit blo=
ck. This led me to correct my assertions by pointing out that our miner pro=
fit equations seemed to be just lower bounds to the miner's true expect=
ed profit. As such, just because the <i>lower bound</i> on the revenue per =
unit hash advantage decreases with the block reward, this doesn't neces=
sarily imply that the <i>real</i>=C2=A0revenue per unit hash advantage does=
also.<br><br>I suspect that the orphaning factor used, independently of th=
e specific form of the block relay time, is incorrect or incomplete as stat=
ed.<div><br></div><div>Best,</div><div>Daniele</div></div><div class=3D"gma=
il_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div dir=3D=
"ltr"><div>Daniele Pinna, Ph.D</div></div></div></div>
<br><div class=3D"gmail_quote">On Tue, Sep 1, 2015 at 10:06 AM, Peter R <sp=
an dir=3D"ltr"><<a href=3D"mailto:peter_r@gmx.com" target=3D"_blank">pet=
er_r@gmx.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><div><div>On 2015-09-01, at 12:56 AM, Peter T=
odd via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote=
</div><span class=3D""><blockquote type=3D"cite"><br>FWIW I did a quick mat=
h proof along those lines awhile back too using<br>some basic first-year ma=
th, again proving that larger miners earn more<br>money per unit hashing po=
wer:<br><br><a href=3D"http://www.mail-archive.com/bitcoin-development@list=
s.sourceforge.net/msg03272.html" target=3D"_blank">http://www.mail-archive.=
com/bitcoin-development@lists.sourceforge.net/msg03272.html</a><br></blockq=
uote><br></span></div><div>I don't believe anyone is arguing otherwise.=
=C2=A0 Miners with a larger fraction of the network hash rate, <i>h</i>/<i>=
H</i>, have a theoretical advantage, all other variables in the miner's=
profitability equation held constant. =C2=A0</div><div><br></div><div>Dpin=
na originally claimed (unless I'm mistaken) that his paper showed that =
this advantage <i>decreased</i> as the block reward diminished or as the to=
tal fees increased.=C2=A0 This didn't seem unreasonable to me, although=
I never checked the math. =C2=A0</div><div><br></div><div>Best regards,</d=
iv><div>Peter</div><div><br></div><div><br></div><div>=C2=A0</div><br></div=
></blockquote></div><br></div>
--089e0160a5e6b3737c051eabad44--
|
