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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VhOmT-0005YN-0N
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 19:10:13 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.95 as permitted sender)
client-ip=62.13.148.95; envelope-from=pete@petertodd.org;
helo=outmail148095.authsmtp.com;
Received: from outmail148095.authsmtp.com ([62.13.148.95])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhOmR-00017m-Qg for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 19:10:12 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt8.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAFJ9jPf014671;
Fri, 15 Nov 2013 19:09:45 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 rAFJ9eHi050028
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 19:09:43 GMT
Date: Fri, 15 Nov 2013 14:09:40 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115190940.GA29469@petertodd.org>
References: <528367F5.9080303@ceptacle.com>
<CAPaL=UWZXSwY9dzX30h_ksj2NAdkyLn3Xtfzs7P8Svg5tsE7Xw@mail.gmail.com>
<20131115095413.GA17034@savin> <5285FBD9.2070106@ceptacle.com>
<20131115111204.GF17034@savin> <52860C56.7000608@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs"
Content-Disposition: inline
In-Reply-To: <52860C56.7000608@ceptacle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 7c6d49f8-4e29-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUFloCAgsB AmUbWl1eUFR7XWA7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ213 fBdLKkBycgVGenY+ ZEZrXXgVWxd8IUJ0
FEZJETgEbHphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMyAx QVgZHDA3GUAfDyAy
KR0jN1tUEkscek47 NVA8XVsEMhgUaEVQ GFtIHStQdREPD3xj
BwRHW1IPUjNaWyRr GBQ0L1hBHDFIUyVV M0FBTBoMECJXXUEw
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: petertodd.org]
X-Headers-End: 1VhOmR-00017m-Qg
Cc: 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 19:10:13 -0000
--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 15, 2013 at 12:58:14PM +0100, Michael Gronager wrote:
> My Q and q are meant differently, I agree to your Q vs Q-1 argument,
> but the q is "me as a miner" participating in "a pool" Q. If I
> participate in a pool I pay the pool owner a fraction, e, but at the
> same time I become part of an economy of scale (well actually a math
> of scale...) and that can end up paying for the lost e. The question
> is what is the ratio q/Q where I should rather mine on my own ? This
> question is interesting as it will make bigger miners break away from
> pools into solo mining, but I also agree that from pure math the most
> advantageous scenario is the 100% mining rig.
The underlying issue is what is the pools expenses compared to yours.
There is an overhead to mining, you need to spend money and time (and
hence money) running and administering full nodes at the very minimum.
The pool can amortise that cost over many hashers; the solo miner can't.
Pools will of course have some profit margin, but why would you expect
that margin to not be sufficiently low to make it in a solo-miner's
interest to join the pool? Both the pool and the former solo-miner earn
more return after all if they centralize.
The fundemental issue is that in the design of Bitcoin there is an
incentive for miners to join into pools, and that incentive exists at
any amount of hashing power. Sure second order effects like regulation
and social pressure can counteract that incentive in some circumstances,
but that's not very strong protection.
> > The equations give an incentive to centralize all the way up to 1
> > miner with 100% hashing power.
> >=20
> > Of course, if that one pool were p2pool, that might be ok!
>=20
> Ha, yes, and then the math for p2pool starts... a math where we have
> much more stales...
However p2pool doesn't necessarily need a linear blockchain to function,
so there is a potential for stales to be much less relevant.
--=20
'peter'[:-1]@petertodd.org
000000000000000772f720b0a231150f22af20760c1463ef920f71ba3daab819
--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJShnF0AAoJEBmcgzuo5/CF+3UIAJc1NaAww4FuGHTZ5ciK1rSw
YCcdsIzeQigl//9jPiilYRA22zhzhTQDxuvINwfAcl/ymhV8MBDNObeGUQuTMJ+A
HMeUNx/aoO9f2d/XbbAuPabkeU1sGoyQprxA5oM8htiGiioJy5p3CigPoWj1IWXU
Fv6bYltnQo/Wr2OF3J5Utcq27GCog7thohiCiIsNwETJN4dE1nnk9gxrmJw8MTwL
LBZKZpHFtesgvA7YHXZlBtzhBvxEPmGRy4d+4klqu7JbIRRfZlAlC2ZbucXGOPM4
GYFsYY+URzGRg2vzzvAO2BbCLkj/SSvaI/L4pcV9mml1MRSp6wyJ0ZCDXnC4MQo=
=SI4r
-----END PGP SIGNATURE-----
--82I3+IH0IqGh5yIs--
|
