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-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jnick@student.ethz.ch>) id 1Z4Bvf-0001mp-81
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 17:42:43 +0000
X-ACL-Warn:
Received: from edge20.ethz.ch ([82.130.99.26])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Z4Bvd-0004KT-6p
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Jun 2015 17:42:43 +0000
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch
(82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1;
Sun, 14 Jun 2015 19:42:26 +0200
Received: from [192.168.0.12] (46.127.137.135) by mail.ethz.ch (172.31.38.212)
with Microsoft SMTP Server (TLS) id 14.3.195.1;
Sun, 14 Jun 2015 19:42:27 +0200
Message-ID: <557DBDCC.5040106@student.ethz.ch>
Date: Sun, 14 Jun 2015 19:45:48 +0200
From: Jonas Nick <jnick@student.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: <bitcoin-development@lists.sourceforge.net>
References: <CAPg+sBi5fYHGLv4wtWbWE7jov8CX=q9UX=vhxDVepG6JfX30+g@mail.gmail.com>
In-Reply-To: <CAPg+sBi5fYHGLv4wtWbWE7jov8CX=q9UX=vhxDVepG6JfX30+g@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [46.127.137.135]
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Z4Bvd-0004KT-6p
Subject: Re: [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: Sun, 14 Jun 2015 17:42:43 -0000
Hi all,
it's a very useful approach to also model fees and you came up with an in=
teresting scenario.
Assuming that you meant that the groups are only connected with a single =
link,
I've recreated the scenario with Gavin's simulation and got similar resul=
ts.
The group with the large hashrate does profit overall, but the miners whi=
ch are not directly
connected to the small group loose:
https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/READM=
E.md#two-groups-well-connected-internally-but-connected-to-each-other-wit=
h-a-single-poor-connection
Moreover, it's important to note that this is not an equilibrium because =
these miners are better off when they create their own
connections to the small group (see the plot below the other one).
This means that your scenario is not the result of a cartel but the resul=
t of a long-term network partition.
When assuming partitions, there are quite a few scenarios where big miner=
s can profit from creating big
blocks. For example, one 40% miner and two groups of three 10% miners, wh=
ere both groups are connected to the big
miner but they are not connected to each other.
https://github.com/jonasnick/bitcoin_miningsim/blob/master/analysis/READM=
E.md#one-big-miner-and-two-partitioned-groups
Best,
Jonas
On 06/12/2015 06:51 PM, Pieter Wuille wrote:
> Hello all,
>
> I've created a simulator for Bitcoin mining which goes a bit further th=
an
> the one Gavin used for his blog post a while ago. The main difference i=
s
> support for links with different latency and bandwidth, because of the
> clustered configuration described below. In addition, it supports diffe=
rent
> block sizes, takes fees into account, does difficulty adjustments, and
> takes processing and mining delays into account. It also simulates long=
er
> 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 mi=
ners
> (one 80%=3D25%+25%+30%, one 20%=3D5%+5%+5%+5%), which are well-connecte=
d
> 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 go=
es
> 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 i=
s
> due to fees, the effect becomes even stronger (a 15% loss), and the opt=
imal
> way to compete for small miners is to create larger blocks as well (sma=
ller
> 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 multipl=
e
> 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 predict=
ion
> for real-world events. However, it does very clearly show the effects o=
f
> larger blocks on centralization pressure of the system. Note that this =
also
> does not make any assumption of destructive behavior on the network - j=
ust
> simple profit maximalization.
>
> Lastly, the code may be buggy; I only did some small sanity tests with
> simple networks.
>
>
>
> -----------------------------------------------------------------------=
-------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
