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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z3SAe-0005T5-TS
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 16:51:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.180 as permitted sender)
client-ip=209.85.223.180; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f180.google.com;
Received: from mail-ie0-f180.google.com ([209.85.223.180])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z3SAd-0004YC-Kk
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 16:51:08 +0000
Received: by iebps5 with SMTP id ps5so28081610ieb.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Jun 2015 09:51:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.56.104 with SMTP id z8mr5610815igp.45.1434127862346; Fri,
12 Jun 2015 09:51:02 -0700 (PDT)
Received: by 10.107.173.77 with HTTP; Fri, 12 Jun 2015 09:51:02 -0700 (PDT)
Date: Fri, 12 Jun 2015 18:51:02 +0200
Message-ID: <CAPg+sBi5fYHGLv4wtWbWE7jov8CX=q9UX=vhxDVepG6JfX30+g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0158a842cc3a18051854e9a1
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z3SAd-0004YC-Kk
Subject: [Bitcoin-development] Mining centralization pressure from
non-uniform propagation speed
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 16:51:08 -0000
--089e0158a842cc3a18051854e9a1
Content-Type: text/plain; charset=UTF-8
Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports different
block sizes, takes fees into account, does difficulty adjustments, and
takes processing and mining delays into account. It also simulates longer
periods of time, and averages the result of many simulations running in
parallel until the variance on the result is low enough.
The code is here: https://github.com/sipa/bitcoin-net-simul
The configuration used in the code right now simulates two groups of miners
(one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
internally, but are only connected to each other through a slow 2 Mbit/s
link.
Here are some results.
This shows how the group of smaller miners loses around 8% of their
relative income (if they create larger blocks, their loss percentage goes
up slightly further):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 16200000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000154
Result:
* Miner group 0: 81.648985% income (factor 1.020612 with hashrate)
* Miner group 1: 18.351015% income (factor 0.917551 with hashrate)
When fees become more important however, and half of a block's income is
due to fees, the effect becomes even stronger (a 15% loss), and the optimal
way to compete for small miners is to create larger blocks as well (smaller
blocks for them result in even less income):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000012500
Result:
* Miner group 0: 83.063545% income (factor 1.038294 with hashrate)
* Miner group 1: 16.936455% income (factor 0.846823 with hashrate)
The simulator is not perfect. It doesn't take into account that multiple
blocks/relays can compete for the same bandwidth, or that nodes cannot
process multiple blocks at once.
The numbers used may be unrealistic, and I don't mean this as a prediction
for real-world events. However, it does very clearly show the effects of
larger blocks on centralization pressure of the system. Note that this also
does not make any assumption of destructive behavior on the network - just
simple profit maximalization.
Lastly, the code may be buggy; I only did some small sanity tests with
simple networks.
--
Pieter
--089e0158a842cc3a18051854e9a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>Hello all,<br><br></div>I=
9;ve created a simulator for Bitcoin mining which goes a bit further than t=
he one Gavin used for his blog post a while ago. The main difference is sup=
port for links with different latency and bandwidth, because of the cluster=
ed configuration described below. In addition, it supports different block =
sizes, takes fees into account, does difficulty adjustments, and takes proc=
essing and mining delays into account. It also simulates longer periods of =
time, and averages the result of many simulations running in parallel until=
the variance on the result is low enough.<br><br></div>The code is here: <=
a href=3D"https://github.com/sipa/bitcoin-net-simul">https://github.com/sip=
a/bitcoin-net-simul</a><br><br></div>The configuration used in the code rig=
ht now simulates two groups of miners (one 80%=3D25%+25%+30%, one 20%=3D5%+=
5%+5%+5%), which are well-connected internally, but are only connected to e=
ach other through a slow 2 Mbit/s link.<br><br></div><div>Here are some res=
ults.<br><br>This shows how the group of smaller miners loses around 8% of =
their=20
relative income (if they create larger blocks, their loss percentage=20
goes up slightly further):<br><br></div>Configuration:<br>=C2=A0 * Miner gr=
oup 0: 80.000000% hashrate, blocksize 20000000.000000<br>=C2=A0 * Miner gro=
up 1: 20.000000% hashrate, blocksize 1000000.000000<br>=C2=A0 * Expected av=
erage block size: 16200000.000000<br>=C2=A0 * Average fee per block: 0.2500=
00<br>=C2=A0 * Fee per byte: 0.0000000154<br>Result:<br>=C2=A0 * Miner grou=
p 0: 81.648985% income (factor 1.020612 with hashrate)<br>=C2=A0 * Miner gr=
oup 1: 18.351015% income (factor 0.917551 with hashrate)<br><br></div>When =
fees become more important however, and half of a block's income is due=
to fees, the effect becomes even stronger (a 15% loss), and the optimal wa=
y to compete for small miners is to create larger blocks as well (smaller b=
locks for them result in even less income):<br><br>Configuration:<br>=C2=A0=
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000<br>=C2=A0 =
* Miner group 1: 20.000000% hashrate, blocksize 20000000.000000<br>=C2=A0 *=
Expected average block size: 20000000.000000<br>=C2=A0 * Average fee per b=
lock: 25.000000<br>=C2=A0 * Fee per byte: 0.0000012500<br>Result:<br>=C2=A0=
* Miner group 0: 83.063545% income (factor 1.038294 with hashrate)<br>=C2=
=A0 * Miner group 1: 16.936455% income (factor 0.846823 with hashrate)<br><=
br></div><div>The simulator is not perfect. It doesn't take into accoun=
t that multiple blocks/relays can compete for the same bandwidth, or that n=
odes cannot process multiple blocks at once.<br><br></div><div>The numbers =
used may be unrealistic, and I don't mean this as a prediction for real=
-world events. However, it does very clearly show the effects of larger blo=
cks on centralization pressure of the system. Note that this also does not =
make any assumption of destructive behavior on the network - just simple pr=
ofit maximalization.<br><br></div><div>Lastly, the code may be buggy; I onl=
y did some small sanity tests with simple networks.<br><br>-- <br></div><di=
v>Pieter<br><br></div></div>
--089e0158a842cc3a18051854e9a1--
|
