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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VhH70-0006Cp-K4
for Bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:58:54 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.112 as permitted sender)
client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
helo=outmail148112.authsmtp.co.uk;
Received: from outmail148112.authsmtp.co.uk ([62.13.148.112])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhH6z-0005wn-Gn for Bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:58:54 +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 rAFAwg42067184;
Fri, 15 Nov 2013 10:58:42 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 rAFAwcdk053943
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 10:58:40 GMT
Date: Fri, 15 Nov 2013 05:58:37 -0500
From: Peter Todd <pete@petertodd.org>
To: Daniel Lidstrom <lidstrom83@gmail.com>
Message-ID: <20131115105837.GE17034@savin>
References: <5279D49D.5050807@jerviss.org>
<CAJHLa0N1-8LfFuWq=vS0r-t2Bt-qZ6yKuGjrnicUOj+K6Gpx5A@mail.gmail.com>
<CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
<20131107034404.GA5140@savin>
<CABsx9T35Po7pUb2sr15zD5WODYqR4-xNvJD0Jz5+Of3d-NjPdg@mail.gmail.com>
<20131107132442.GB22476@savin>
<CANEZrP3T4qsz8qqPxqtP5oXNYA_WT5OQPrC2uAKuQyDqJ0N9Rw@mail.gmail.com>
<CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="BZaMRJmqxGScZ8Mx"
Content-Disposition: inline
In-Reply-To: <CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e38c8c85-4de4-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bwdMdwcUFloCAgsB AmUbWlReVVV7XWI7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcGpw QU1KCRl3dAxCezBy Y05jWj4OX0wpfRV1
R1NQQTgCeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4UE3Y3 ThZKFDErVVcIQywj ZxohNTb9
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: 1VhH6z-0005wn-Gn
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>, webmaster@cex.io,
webmaster@ghash.io
Subject: Re: [Bitcoin-development] we can all relax now
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 10:58:54 -0000
--BZaMRJmqxGScZ8Mx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 07, 2013 at 11:28:52AM -0700, Daniel Lidstrom wrote:
> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
>=20
> Suppose a cabal with fraction q of the total hashing power is n blocks
> ahead on a secret branch of that has mined r_tot coins, and let r_next be
> its next block's reward. If the cabal chooses not to broadcast its secret
> chain until at least the next block, its expected revenue after the next
> block is found is
>=20
> (1 - (1-q)^(n+1))*(r_tot + r_next)
>=20
> If it does broadcast, its expected revenue after the next block is found =
is
>=20
> r_tot + q * r_next
>=20
> If the cabal seeks only to maximize immediate revenue, then after a bit of
> algebra we find that it will withhold its chain if
>=20
> q > 1 - ( 1 + r_tot / r_next )^(-1/n)
>=20
> So if the cabal has just mined his first block off of the public chain,
> i.e. n =3D 1, and if the block reward is relatively stable, i.e. r_next =
=3D
> r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
> calculated.
>=20
> From this formula we can also see that if the miner wins the race and
> withholds again, then he must grow q to compensate for the increase in
> r_tot, and any decrease in n. So generally publication becomes
> increasingly in the cabal's interest, and secret chains will tend not to
> grow too large (intuition tells me that simulations using the above formu=
la
> should bear this out).
>=20
> This seem correct to you?
Remember how I started off by asking what was the correct strategy if a
miner wanted to get more blocks than their *competition*, not more
blocks in total. In some scenarios that strategy is the one that
maximizes returns, such as the case when you make your returns from
transaction fees, especially without a blocksize limit restricting how
many fee paying transactions you can stuff in your blocks. It's not
correct to say the cabal is trying to maximize immediate revenue.
As for the length of those secret chains, at every step you of course
want to weigh the value of the blocks you have found against the risk
that someone else catches up, and when it makes sense, publish some or
all.
--=20
'peter'[:-1]@petertodd.org
0000000000000000b4ff49cd2cad865d6cbca99828987a02f3d5f41067eab00a
--BZaMRJmqxGScZ8Mx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJShf5dXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBiNGZmNDljZDJjYWQ4NjVkNmNiY2E5OTgyODk4N2EwMmYz
ZDVmNDEwNjdlYWIwMGEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftfTwgAkfxoN0j1V52KDAWm+zCaVnbc
L6NfXySpFK20KtsjoiijzMLtCoq29hqjLJwbVAYlikH4Wzd7p2xPMcsee06sAyTI
6DPicmk8ciKYG4ss3JyVGH1zE88mYikKEGcN9niVMktUcOLhkF+bB0mQwiYL/9Fm
dBkISVLTTJO5cy4rs+93h9/+VgLskO8v3F5EiJUwgzp2WiPUzJXlBnTibCMxEiMN
/fyuqdGv9rfVrlrogOJSFyTsYM2P+2+SWNoU650PRwnCnqqTk+/hmE5WG+26PG2V
TRtYeaAdjc1NtHFl2KxCfdaCpO4NbkjzuAFfOnoW6MTa3eqwkqE9pKDfrJ9eJQ==
=aSU+
-----END PGP SIGNATURE-----
--BZaMRJmqxGScZ8Mx--
|
