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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VeGW4-0008Vz-RA
for Bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 03:44:20 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VeGW2-0004ra-MB for Bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 03:44:20 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA73i9V8090464;
Thu, 7 Nov 2013 03:44:09 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 rA73i58d002104
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 7 Nov 2013 03:44:07 GMT
Date: Wed, 6 Nov 2013 22:44:04 -0500
From: Peter Todd <pete@petertodd.org>
To: Christophe Biocca <christophe.biocca@gmail.com>
Message-ID: <20131107034404.GA5140@savin>
References: <5279D49D.5050807@jerviss.org>
<CAJHLa0N1-8LfFuWq=vS0r-t2Bt-qZ6yKuGjrnicUOj+K6Gpx5A@mail.gmail.com>
<CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: db47f7e3-475e-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgUUFloCAgsB AmUbW1deVFl7WWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcBsC XxsWBhlydQRGfDBz ZUJjXD4PDkB9I0Eo
QVNQEmhTeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4UE3Y3 ThZKFDErVVcIQywj ZxohNTb9
X-Authentic-SMTP: 61633532353630.1023: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: 1VeGW2-0004ra-MB
Cc: Bitcoin-development@lists.sourceforge.net
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: Thu, 07 Nov 2013 03:44:21 -0000
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 06, 2013 at 01:06:47PM -0500, Christophe Biocca wrote:
> I might try building this sometime soon. I think it may also serve an
> educational purpose when trying to understand the whole network's behavio=
ur.
>=20
> What level of accuracy are we looking for though? Obviously we need to
> fully emulate the steps of the network protocol, and we need to be able to
> specify time taken for transmission/processing for each node. Do we care
> about the actual contents of the messages (to be able to simulate double
> spend attempts, invalid transactions and blocks, SPV node communication),
> and their validation (actual signatures and proof of work)?
>=20
> I imagine the latter is pretty useless, beyond specifying that the
> signature/proof of work is valid/invalid.
>=20
> If we could build up a set of experiments we'd like to run on it, it would
> help clarify what's needed.
>=20
> Off the top of my head:
>=20
> - Peter Todd's miner strategy of sending blocks to only 51% of the
> hashpower.
Speaking of, I hadn't gotten around to doing up the math behind that
strategy properly; turns out 51% I was overly optimistic and the actual
threshold is 29.3%
Suppose I find a block. I have Q hashing power, and the rest of the
network 1-Q. Should I tell the rest of the network, or withhold that
block and hope I find a second one?
Now in a purely inflation subsidy environment, where I don't care about
the other miners success, of course I should publish. However, if my
goals are to find *more* blocks than the other miners for whatever
reason, maybe because transaction fees matter or I'm trying to get
nLockTime'd announce/commit fee sacrifices, it gets more complicated.
There are three possible outcomes:
1) I find the next block, probability Q
2) They find the next block, probability 1-Q
2.1) I find the next block, probability Q, or (1-Q)*Q in total.
2.2) They find the next block, probability (1-Q)^2 in total.
Note how only in the last option do I lose. So how much hashing power do
I need before it is just as likely that the other miners will find two
blocks before I find either one block, or two blocks? Easy enough:
Q + (1-Q)*Q =3D (1-Q)^2 -> Q^2 - Q + 1/2 -> Q =3D (1 - \sqrt(2))/2
Q ~=3D 29.2%
So basically, if I'm trying to beat other miners, once I have >29.3% of
the hashing power I have no incentive to publish the blocks I mine!
But hang on, does it matter if I'm the one who actually has that hashing
power? What if I just make sure that only >29.3% of the hashing power
has that block? If my goal is to make sure that someone does useless
work, and/or they are working on a lower height block than me, then no,
I don't care, which means my original "send blocks to >51% of the
hashing power" analysis was actually wrong, and the strategy is even
more crazy: "send blocks to >29.3% of the hashing power" (!)
Lets suppose I know that I'm two blocks ahead:
1) I find the next block: Q (3:0)
2) They find the next block: (1-Q) (2:1)
2.1) I find the next block: (1-Q)*Q (3:1)
2.2) They find the next block: (1-Q)^2 (2:2)
2.2.1) I find the next block: (1-Q)^2 * Q (3:2)
2.2.2) They find the next block: (1-Q)^3 (2:3)
At what hashing power should I release my blocks? So remember, I win
this round on outcomes 1, 2.1, 2.2.1 and they only win on 2.2.2:
Q + (1-Q)*Q + (1-Q)^2*Q =3D (1-Q)^3 -> Q =3D 1 - 2^-3
Q ~=3D 20.6%
Interesting... so as I get further ahead, or to be exact the group of
miners who have a given block gets further ahead, I need less hashing
power for my incentives to be to *not* publish the block I just found.
Conversely this means I should try to make my blocks propagate to less
of the hashing power, by whatever means necessary.
Now remember, none of the above strategy requires me to have a special
low-latency network or anything fancy. I don't even have to have a lot
of hashing power - the strategy still works if I'm, say, a 5% pool. It
just means I don't have the incentives people thought I did to propagate
my blocks widely.
The other nasty thing about this, is suppose I'm a miner and recently
got a block from another miner: should I forward that block, or not
bother? Well, it depends: if I have no idea how much of the hashing
power has that block, I should forward the block. But again, if my goal
is to be most likely to get the next block, I should only forward in
such a way that >30% of the hashing power has the block.
This means that if I have some information about what % already has that
block, I have less incentive to forward! For instance, suppose that
every major miner has been publishing their node addresses in their
blocks - I'll have a pretty good idea of who probably has that most
recent block, so I can easily make a well-optimized decision not to
forward. Similarly because the 30% hashing power figure is the
*integral* of time * hashes/second, if miners are forwarding
near-target-headers, I might as well wait a few seconds and see if I see
any near-target-headers; if I do for this block then I have evidence
that hashing power does have it, and I shouldn't forward.
So yeah, we're fucked and have got to fix this awful incentive structure
somehow before the inflation subsidy gets any smaller. Also, raising the
blocksize, especially by just removing the limit, is utter madness given
it can be used to slow down block propagation selectively, so the
hashing power that gets a given block is limited repeatably to the same
group.
P.S: If any large pools want to try this stuff out, give me a shout. You
have my PGP key - confidentiality assured.
P.P.S: If you're mining on a pool with more than, like, 1% hashing
power, do the math on varience... Seriously, stop it and go mine on a
smaller pool, or better yet, p2pool.
--=20
'peter'[:-1]@petertodd.org
00000000000000078b970f5134bae96da021744f80e04aa9dc2e2d2c2bcb07c2
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJSewyEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDM2Nzc5MWJhOWY2YTA5YTMwZjlkZjMyMWE3MDVlZmFmNWZk
MmYxYmY0MjlmM2I1NTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfubwgf/fsQF4g1M6HfPODGdPLEEsEDQ
2a94rOTMlRY5hFLi9sx/i5F4p9/HOdTlqmi9p2pq5KyZ7QC/tInx6VToNPm9ikJP
z8qurbYyizj6GZhEk51jOxmJn4KIr39uihENd4TmIfYc3EIFvKmz9QtSP4WC58gb
g0uuPl8ZWjj/9fxDjIf7ZRkJbgsaula14WBamYAq7zQIAUzQz8k9ny5IKsgSkPqP
3rdZjMMjUhDWHzaG6toOqgAWTh/2NOYSUkLVMYtx3UH1i4X7y/K/btEw+mZqy5DQ
X2R5TrFomoVeKumUaQkg4xH6f1yMT1xyuC9wSR3v8omKfpnhaXT29PB53aveMQ==
=kBA+
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
|
