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
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VeWFR-0005R8-JT
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 20:32:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.107 as permitted sender)
client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
helo=outmail148107.authsmtp.com;
Received: from outmail148107.authsmtp.com ([62.13.148.107])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VeWFP-0007Ro-OF for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 20:32:13 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA7KVVeS097485;
Thu, 7 Nov 2013 20:31:31 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA7KVOx3007816
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 7 Nov 2013 20:31:26 GMT
Date: Thu, 7 Nov 2013 15:31:23 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131107203123.GB3805@petertodd.org>
References: <527B9F9B.4060808@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb"
Content-Disposition: inline
In-Reply-To: <527B9F9B.4060808@ceptacle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 93ce76cf-47eb-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgUUFloCAgsB AmUbWVReU1x7W2Q7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20G fXhhGhpydwJOeXg+ Z0ZmXnMVVUcpIEF7
ERhJEWpTN3phaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOTh0 WxAPVTI3AUwATiF7
JRghIV1UB0cDPw07 N1dpRlIJUVcOEARY BEhGHC5eIREPSicw
RQpAUAZOWCFcRCpH SgEvJVdMBSMaGi1C TFdfQhcUAihZUS5O
U34NGjEsCVUyb14t NWwVMA5wcwAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: mail-archive.com]
X-Headers-End: 1VeWFP-0007Ro-OF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big)
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, 07 Nov 2013 20:32:13 -0000
--8GpibOaaTibBMecb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> Final conclusions is that the fee currently is too small and that there
> is no need to keep a maximum block size, the fork probability will
> automatically provide an incentive to not let block grows into infinity.
Your definition of P_fork is inaccurate for a miner with non-negligable
hashing power - a miner will never fork themselves. Taking that into
account we have three outcomes:
1) The block propagates without any other miner finding a block.
2) During propagation another miner finds a block. (tie)
2.1) You win the tie by finding another block.
2.2) You lose the tie because someone else finds a block.
We will define t_prop as the time it takes for a block to propagate from
you to 100% of the hashing power, and as a simplifying assumption we
will assume that until t_prop has elapsed, 0% of the hashing power has
the block, and immedately after, 100% has the block. We will also define
t_int, the average interval between blocks. (600 seconds for Bitcoin)
Finally, we will define Q as the probability that you will find the next
block.
The probabilities of the various outcomes:
1) 1 - (t_prop/t_int * (1-Q))
2) t_prop/t_int * (1-Q)
2.1) Q
2.2) 1-Q
Note that to simplify the equations we have not taking into account
propagation in our calculations for outcomes 2.1 or 2.2
Thus we can define P_fork taking into account Q:
P_fork(Q) =3D (t_prop/t_int * (1-Q))(1-Q) =3D t_pop/t_int * (1-Q)^2
Over the range 0 < Q < 0.5 the probability of a fork decreases
approximately linearly as your hashing power increases:
d/dq P_fork(Q) =3D 2(Q-1)
Q=3D0 -> d/dq P_fork(Q) =3D -2
Q=3D1/2 -> d/dq P_fork(Q) =3D -1
With our new, more accurate, P_fork(Q) function lets re-calculate the
break-even fee/KB using your original approach:
t_prop =3D t_0 + \alpha*S
E_fee =3D f*S
E(Q) =3D Q*(1 - P_fork(Q))*(E_bounty + E_fee)
E(Q) =3D Q*[1 - (t_0 + k*S)/t_int * (1-Q)^2]*(E_B + f*S)
d/dS E(Q) =3D Q*[ -2fSk/t_int*(1-Q)^2 - f*t_0/t_int*(1-Q)^2 + f - E_b*k/t_i=
nt*(1-Q)^2 ]
Again, we want to choose the fee so that the more transactions we
include the more we earn, dE/dS > 0 We find the minimum fee to include a
transaction at all by setting S=3D0, thus we get:
d/dS E(Q, S=3D0) =3D Q*[ f - f*t_0/t_int*(1-Q)^2 - E_b*k/t_int*(1-Q)^2 ] > 0
f(1 - t_0/t_int*(1-Q)^2) > E_b*k/t_int*(1-Q)^2
f > [E_b*k/t_int(1-Q)^2] / [1 - t_0/t_int*(1-Q)^2]
f > [E_b*k*(1-Q)^2] / [t_int - t_0*(1-Q)^2]
With Q=3D0:
f > E_b*k / (t_int - t_0) ~ E_b*k/t_int
This is the same result you derived. However lets look at Q !=3D 0:
df/dQ =3D 2*E_b*k * [t_int*(q-1)] / [t_int - t_0(q-1)^2]^2
With negligible latency we get:
df/dQ, t_0=3D0 =3D 2*E_b*k*(q-1)/t_int
So what does that mean? Well in the region 0 < q < 1/2, df/dQ is always
negative. In other words, as you get more hashing power, the fee/KB you
can charge and still break even decreases linearly because you will
never orphan yourself. Lets trythe same assumptions as your first
analysis, based on the work by Decker et al
Based on the work by Decker et al, lets try to calculate break-even
fee/KB for negligible, 10%, 25% and 40% hashing power:
t_0 =3D 10s
t_int =3D 600s
k =3D 80ms/kB
E_b =3D 25BTC
Q=3D0 -> f =3D 0.0033 BTC/kB
Q=3D0.1 -> f =3D 0.0027 BTC/kB
Q=3D0.25 -> f =3D 0.0018 BTC/kB
Q=3D0.40 -> f =3D 0.0012 BTC/kB
Let's assume every miner is directly peered with every other miner, each
of those connections is 1MB/s, and somehow there's no latency at all:
k =3D 1mS/kB
Q=3D0 -> f =3D 0.000042 BTC/kB
Q=3D0.1 -> f =3D 0.000034 BTC/kB
Q=3D0.25 -> f =3D 0.000023 BTC/kB
Q=3D0.40 -> f =3D 0.000015 BTC/kB
Regardless of how you play around with the parameters, being a larger
miner has a significant advantage because you can charge lower fees for
your transactions and therefor earn more money. But it gets even more
ugly when you take into account that maybe a guy with 0.1% hashing power
can't afford the high bandwidth, low-latency, internet connection that
the larger pool has:
k =3D 10mS/kB, t_0=3D5s, Q=3D0.01 -> 0.000411 BTC/KB
k =3D 1mS/kB, t_0=3D1s, Q=3D0.15 -> 0.000030 BTC/KB
So the 1% pool has an internet connection capable of 100kB/s to each
peer, taking 5s to reach all the hashing power. The 15% pool can do
1MB/s to each peer, taking 1s to reach all the hashing power. This small
different means that the 1% pool needs to charge 13.7x more per KB for
their transactions to break even! It's a disaster for decentralization.
Businesses live and die on percentage points, let alone orders of
magnitude differences in cost, and I haven't even taken into account
second-order effects like the perverse incentives to publish your blocks
to only a minority of hashing power.(1)
This problem is inherent to the fundemental design of Bitcoin:
regardless of what the blocksize is, or how fast the network is, the
current Bitcoin consensus protocol rewards larger mining pools with
lower costs per KB to include transactions. It's a fundemental issue. An
unlimited blocksize will make the problem even worse by increasing fixed
costs, but keeping the blocksize at 1MB forever doesn't solve the
underlying problem either as the inflation subsidy becomes less
important and fees more important.
1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms=
g03200.html
--=20
'peter'[:-1]@petertodd.org
00000000000000054eeccf3ac454892457bf4919d78efb275efd2ddd1a920c99
--8GpibOaaTibBMecb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSe/ibAAoJEBmcgzuo5/CFiLAH/Rq/O7J61kSi4WZOM30DA0EI
Hv4jhK3kkT9NGTl2MFgGLtz1eKZC37Y3TNnuVei0Q0muyb2K30fHvk9mAOBXOnbY
bSaPoiV4lG06t0HrMUcOD2ISC7VrB/Gm59ScV3eWW7qFlndkC2NeJvJUMrYg3PRN
R2XhNwTtPXKEEg0sSmoTJ3RRQ8FX3fcXrFiWrXBK2KZWJDtLcK81Ua4npuQdjaON
WI3ozXFsPK+ptDTn8bSouWPYg95FYSMLTA5xoN0tmmrdvz+DzYdhrL6Ium+VYcWS
guFMC+OOHp6nLO0KWT7LEUh0dgpRCk6e0l0syPrpUphjLJHpjKxJEkk9pWbX9Pg=
=7pgc
-----END PGP SIGNATURE-----
--8GpibOaaTibBMecb--
|
