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
189
190
191
192
193
194
195
196
197
198
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1U5rzY-0001Zx-6M
for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 06:08:20 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.113 as permitted sender)
client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
helo=outmail148113.authsmtp.com;
Received: from outmail148113.authsmtp.com ([62.13.148.113])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1U5rzU-0003Gg-WD for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 06:08:20 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r1E688d5031959; Thu, 14 Feb 2013 06:08:08 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r1E682qO032896
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 14 Feb 2013 06:08:04 GMT
Date: Thu, 14 Feb 2013 01:07:44 -0500
From: Peter Todd <pete@petertodd.org>
To: Stephen Pair <stephen@bitpay.com>
Message-ID: <20130214060744.GA15157@savin>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
<CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
<CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr"
Content-Disposition: inline
In-Reply-To: <CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e5bdb601-766c-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwYUHlAWAgsB AmUbW1JeUFV7WWY7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqAGkH DhxfLRlxdQ1PfjBy bU9gWj4OWRYuJ0B9
Q1NTE2tVeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4qGDU7 XQgFBzwzHEsKDy83
KBclYkAVGEcdO1kz Nl1pQ08cPn1aDwpS Hk9MCyZFJl4HXGIq
Cx9dFVIeHXVXRSBX AVUjIhZJBFQA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1U5rzU-0003Gg-WD
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
modifications into the block chain
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: Thu, 14 Feb 2013 06:08:20 -0000
--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
> One of the beauties of bitcoin is that the miners have a very strong
> incentive to distribute as widely and as quickly as possible the blocks
> they find...they also have a very strong incentive to hear about the bloc=
ks
> that others find. There will not be an issue with blocks being "jealously
The idea that miners have a strong incentive to distribute blocks as
widely and as quickly as possible is a serious misconception. The
optimal situation for a miner is if they can guarantee their blocks
would reach just over 50% of the overall hashing power, but no more. The
reason is orphans.
Here's an example that makes this clear: suppose Alice, Bob, Charlie and
David are the only Bitcoin miners, and each of them has exactly the same
amount of hashing power. We will also assume that every block they mine
is exactly the same size, 1MiB. However, Alice and Bob both have pretty
fast internet connections, 2MiB/s and 1MiB/s respectively. Charlie isn't
so lucky, he's on an average internet connection for the US,
0.25MiB/second. Finally David lives in country with a failing currency,
and his local government is trying to ban Bitcoin, so he has to mine
behind Tor and can only reliably transfer 50KiB/second.
Now the transactions themselves aren't a problem, 1MiB/10minutes is just
1.8KiB/second average. However, what happens when someone finds a block?
So Alice finds one, and with her 1MiB/second connection she
simultaneously transfers her new found block to her three peers. She has
enough bandwidth that she can do all three at once, so Bob has it in 1
second, Charlie 4 seconds, and finally David in 20 seconds. The thing
is, David has effectively spent that 20 seconds doing nothing. Even if
he found a new block in that time he wouldn't be able to upload it to
his other peers fast enough to beat Alices block. In addition, there was
also a probabalistic time window *before* Alice found her block, where
even if David found a block, he couldn't get it to the majority of
hashing power fast enough to matter. Basically we can say David spent
about 30 seconds doing nothing, and thus his effective hash power is now
down by 5%
However, it gets worse. Lets say a rolling average mechanism to
determine maximum block sizes has been implemented, and since demand is
high enough that every block is at the maximum, the rolling average lets
the blocks get bigger. Lets say we're now at 10MiB blocks. Average
transaction volume is now 18KiB/second, so David just has 32KiB/second
left, and a 1MiB block takes 5.3 minutes to download. Including the time
window when David finds a new block but can't upload it he's down to
doing useful mining a bit over 3 minutes/block on average.
Alice on the other hand now has 15% less competition, so she's actually
clearly benefited from the fact that her blocks can't propegate quickly
to 100% of the installed hashing power.
Now I know you are going to complain that this is BS because obviously
we don't need to actually transmit the full block; everyone already has
the transactions so you just need to transfer the tx hashes, roughly a
10x reduction in bandwidth. But it doesn't change the fundemental
principle: instead of David being pushed off-line at 10MiB blocks, he'll
be pushed off-line at 100MiB blocks. Either way, the incentives are to
create blocks so large that they only reliably propegate to a bit over
50% of the hashing power, *not* 100%
Of course, who's to say Alice and Bob are mining blocks full of
transactions known to the network anyway? Right now the block reward is
still high, and tx fees low. If there isn't actually 10MiB/second of
transactions on the network it still makes sense for them to pad their
blocks to that size anyway to force David out of the mining business.
They would gain from the reduced hashing power, and get the tx fees he
would have collected. Finally since there are now just three miners, for
Alice and Bob whether or not their blocks ever get to Charlie is now
totally irrelevant; they have every reason to make their blocks even
bigger.
Would this happen in the real world? With pools chances are people would
quit mining solo or via P2Pool and switch to central pools. Then as the
block sizes get large enough they would quit pools with higher stale
rates in preference for pools with lower ones, and eventually the pools
with lower stale rates would probably wind up clustering geographically
so that the cost of the high-bandwidth internet connections between them
would be cheaper. Already miners are very sensitive to orphan rates, and
will switch pools because of small differences in that rate.
Ultimately the reality is miners have very, very perverse incentives
when it comes to block size. If you assume malice, these perverse
incentives lead to nasty outcomes, and even if you don't assume malice,
for pool operators the natural effects of the cycle of slightly reduced
profitability leading to less ability invest in and maintain fast
network connections, leading to more orphans, less miners, and finally
further reduced profitability due to higher overhead will inevitably
lead to centralization of mining capacity.
--=20
'peter'[:-1]@petertodd.org
--liOOAslEiF7prFVr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRHH8vAAoJEH+rEUJn5PoE9bwH/3JUYA026jqy9VX8hO8csC7t
7Lyuw/cgTLqeW2e2Im7CTh6vOwg3uZSBOb41lnE5fy+Lj+Rg84dGkpUBrjYVd5zM
BtcNlwgKKnZfehMRv2NUs/hjrobGPathPMJW/M0OsMZKBxT1iJFBi/A/EoR58b6L
QBBYmIcwxHDVP0ru4EJOW+zBbZR5XobH4Eev9K86IIulQ4VKezY0wOpBRKqZ7dX/
K8jbiGNwnR4Fg3QSIHRKnktpckPq3DaVPbk1Df552cGHDGfLKMH+l08Td04xCK8C
f+hKOXBSFDp499nX05BcCjsvE3P2GJ2qxs7maRpNO5jRERhxp1ZKNjXpr+NXtNY=
=Lkx4
-----END PGP SIGNATURE-----
--liOOAslEiF7prFVr--
|
