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
|
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 636F8DFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 16:43:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com
[209.85.215.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ABC62A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 16:43:44 +0000 (UTC)
Received: by laba3 with SMTP id a3so48619489lab.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 09:43:43 -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=4SFSen8UFmJHWt3Uzu/u2rVoU62cPmA2kQZI6itDRrg=;
b=Q+IJp7oZ+zz3i+qVLLN9JV8w7e4+QQbazbSltQTERyCzd4G+Ro11dsb6JjgCEnzMAs
tqEhIccljbPnFw61rUCTRn4+ll/TeAWgmfLmt0CpLjFyhLXEqGJgtw0su+7jy8UAfCxg
EDA0HY9hV/q0m8v1sXcx2KNl2roH9VTLAE0gr5LNz+oy+22HFtDiM3xt9oZBqmun834/
dGK+5zZy85gae449dtFN4lt3wKC8q0ITvou8LkicRoFL+3f7cOc9rWXgkwMKZ5WJD1oQ
WISb4IQ4MErIQ4p3Zrk7SCKdAh7eGRoLDAo0LU6sBnpCh8aP1f5seIqF9s6p8PhYXvi6
Jn1A==
X-Received: by 10.152.5.40 with SMTP id p8mr7499185lap.10.1440866622976; Sat,
29 Aug 2015 09:43:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.143.229 with HTTP; Sat, 29 Aug 2015 09:43:23 -0700 (PDT)
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Sat, 29 Aug 2015 18:43:23 +0200
Message-ID: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e013d116e3b3ca1051e75e783
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
Subject: [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 16:43:46 -0000
--089e013d116e3b3ca1051e75e783
Content-Type: text/plain; charset=UTF-8
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.
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.
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.
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.
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
Regards,
Daniele
--089e013d116e3b3ca1051e75e783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'd like to submit this paper to the dev-list whi=
ch 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 c=
ritiques made by the community to his work.</div><div><br>The main result o=
f the work is a detailed analysis of mining advantages (defined as the adde=
d profit per unit of hash) as a function of miner hashrate. In it, I show h=
ow large block subsidies (or better, low mempool fees-to-subsidy ratios) in=
centivize the pooling of large hashrates due to the steady increasing of ma=
rginal profits as hashrates grow.=C2=A0</div><div><br></div><div>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 w=
hich has access to expected profits an order of magnitude larger than every=
one else. As block subsidies decrease, this high-efficiency class is expect=
ed to vanish leading to a marginal profit structure which decreases as a fu=
nction of hashrate.</div><div><br></div><div>This work has vacuumed my enti=
re 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 b=
lock size scaling proposal (BIP101) which, due to the XT fork drama, I beli=
eve has been placed hastily and undeservedly on the chopping block.</div><d=
iv><br></div><a href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-=
of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.=
com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-=
Fee-Markets</a>
<div><br></div><div>Regards,</div><div>Daniele</div></div>
--089e013d116e3b3ca1051e75e783--
|
