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
|
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 <pete@petertodd.org>) id 1VhHJx-0004wj-Ob
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 11:12:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhHJw-0004ek-B4 for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 11:12:17 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAFBCA1q001010;
Fri, 15 Nov 2013 11:12:10 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 rAFBC5mb093294
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 11:12:07 GMT
Date: Fri, 15 Nov 2013 06:12:04 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115111204.GF17034@savin>
References: <528367F5.9080303@ceptacle.com>
<CAPaL=UWZXSwY9dzX30h_ksj2NAdkyLn3Xtfzs7P8Svg5tsE7Xw@mail.gmail.com>
<20131115095413.GA17034@savin> <5285FBD9.2070106@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ExXT7PjY8AI4Hyfa"
Content-Disposition: inline
In-Reply-To: <5285FBD9.2070106@ceptacle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: c46fd746-4de6-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUFloCAgsB AmUbWlVeUV97WWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcGpz dRtDABl7dAdPfDBx YkNnWD4IWEIsIUF5
RFNQQTgAeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4mADM6 DwsDGC0rEFdNQiQ1
Lhk7LxYSEUtZOUw2 OkYlUE4ZNBlwQgNZ BURQBCYLb1dJEWIh
Ch5cQV9cHjpHQhBG CwElZRZWDyZbVSdv Dk9CQBIUCjFIOCIS
X-Authentic-SMTP: 61633532353630.1024: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
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: petertodd.org]
X-Headers-End: 1VhHJw-0004ek-B4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation
formula: f > bounty*fork_rate/average_blocksize
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, 15 Nov 2013 11:12:17 -0000
--ExXT7PjY8AI4Hyfa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi Peter,
>=20
> Love to see things put into formulas - nice work!
>=20
> Fully agree on the your fist section: As latency determines maximum
> block earnings, define a 0-latency (big-miner never orphans his own
> blocks) island and growing that will of course result in increased earnin=
gs.
>=20
> So build your own huge mining data center and you rock.
>=20
> However, that is hardly the real work scenario today. Instead we have
> pools (Huge pools). It would be interesting to do the calculation:
>=20
> Q =3D Total pool size (fraction of all mining power)
> q =3D My mining power (do.)
> e =3D fraction of block fee that pool reserves
>=20
> It is pretty obvious that given your formulas small miners are better
> off in a pool (can't survive as solo miners), but there will be a
> threshold q_min above which you are actually better off on you own -
> depending also on e. (excluding here all benefits of a stable revenue
> stream provided by pools)
Unfortunately the math doesn't work that way. For any Q, a bigger Q
gives you a higher return. Remember that the way I setup those equations
in section 3.2 is such that I'm actually modeling two pools, one with Q
hashing power and one with (1-Q) hashing power. Or maybe more
accurately, it's irrelevant if the (1-Q) hashing power is or isn't a
unified pool.
The other thing is the fraction of the block fee the pool reserves
indicates you're talking about real-world costs... and the moment you do
that you find that pools themselves have economies of scale simply by
virtue of using a small overhead infrastructure, their nodes etc., for a
large number of miners. On that basis alone a small miner joining a
larger pool would always be financially advantageous modulo situations
where the large pool had legal restrictions that artificially increased
their overheads.
> Next interesting calculation would be bitcoin rate as a function of pool
> size, I expect a sharp dip somewhere in the 40%s of hardware controlled
> by one entity ;)
Bitcoin rate?
> Finally, as you mention yourselves, qualification of the various
> functions is needed. This could e.g. suggest if we are like to get 3 or
> 10 miners on the long run.
The equations give an incentive to centralize all the way up to 1 miner
with 100% hashing power.
Of course, if that one pool were p2pool, that might be ok!
> And now for section 2. You insert a definition of f(L) =3D a-bL. I think
> the whole idea of letting f depend on L is superfluous. As a miner you
> are always free to choose which transactions to include. You will always
> choose those with the biggest fee, so really it is only the average fee
> that is relevant: f(L) =3D c. Any dependence in L will be removed by the
> reshuffeling. To include an extra transaction will require either that
> it has a fee larger than another (kicking that out out) or that it has a
> fee so large that it covers for the other transaction too. Also recall
> that there is a logical minimum fee (as I have already shown), and a
> maximum optimal block size - that is until the bounty becomes 0 (which
> is where other effects kick in).
By defining f(L) you can model supply and demand, which can be relevant
in that a steep demand curve with a small number of high-fee
transactions can reduce centralization pressure in my model.
Of course, by defining f(L) =3D a-bL you also wind up with mathematica
spitting out some truly hideous polynomials. :P Setting f(L) =3D c as you
suggest is something I looked at, and results in equations that are more
reasonable, so I think I'll likely wind up doing that. You can make a
good argument anyway that the centralization would cause a flattening of
any demand curve anyway, as in the no-blocksize-limit case the larger
pools cost per transaction tends towards zero as their hashing power
increases - why pay high fees when the large pool will mine them almost
as fast?
--=20
'peter'[:-1]@petertodd.org
0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a
--ExXT7PjY8AI4Hyfa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJShgGEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDI1YjZhODJkZDcyMTgxMzY5YzI3OTkwOTRiZTNlOGE4MDQ0
YjhiYjk2OTljOTZkMTYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuAxQgAgGqNvC/nxYnAHvY+D1ByWZKE
yXPVuytAqKLbHcVJryntw/ZsT4P8XGE0uXZav0USP6Lt9uJDAkAWR+HjDvLfFbC6
SypEgm50kurew+1VOX8Bmnc8w4w9ky5TUR+PL12b9Wn7hbdhkuCvl24P2mxPA4Td
CHOP77HgfUrpmIWFui4g/43n+T8vBA7YULnrPVaWMnqSe6QCcF6WrJJVt3IweZ6w
7X+Ex7lxC+i0czkLbIg4sPPDMT87bbSjFCM+0G7jsAPCovnLGJ0VMEJ7kVQjsJeS
eV3CjSjyTnwdzdBEY2Le34AXk2ELnOGV69uRvFRjH7qeuogzuUugWxMwWlHW4A==
=hbd3
-----END PGP SIGNATURE-----
--ExXT7PjY8AI4Hyfa--
|
