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
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <SRS0=QJoVlpPy=UQ=jerviss.org=kjj@jerviss.org>)
id 1VeI5Y-0005OE-1c for Bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 05:25:04 +0000
X-ACL-Warn:
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1VeI5U-0001Ru-Ln
for Bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 05:25:04 +0000
Received: from [10.8.2.254] ([192.151.168.109])
(username: kjj authenticated by PLAIN symmetric_key_bits=0)
by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id rA75OoQs022193
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 6 Nov 2013 23:24:53 -0600
Message-ID: <527B2420.6030603@jerviss.org>
Date: Wed, 06 Nov 2013 23:24:48 -0600
From: Kyle Jerviss <kjj@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
rv:25.0) Gecko/20100101 SeaMonkey/2.22
MIME-Version: 1.0
To: Christophe Biocca <christophe.biocca@gmail.com>,
Bitcoin-development@lists.sourceforge.net
References: <5279D49D.5050807@jerviss.org> <CAJHLa0N1-8LfFuWq=vS0r-t2Bt-qZ6yKuGjrnicUOj+K6Gpx5A@mail.gmail.com>
<CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
In-Reply-To: <CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------030006090905040104020208"
Received-SPF: pass (inana.jerviss.org: 192.151.168.109 is authenticated by a
trusted mechanism)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
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: doubleclick.net]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VeI5U-0001Ru-Ln
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 05:25:04 -0000
This is a multi-part message in MIME format.
--------------030006090905040104020208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
What I want is configurable 1/10/100 millisecond ticks, and accurate
flow of information.
It doesn't seem necessary to really emulate the whole protocol, nor to
be overly concerned with the content of messages, nor to simulate every
little housekeeping step or network message.
I'm not looking for a bitcoin-network-in-a-bottle, I just want to see
flows. In the current situation, how often does a miner win if they
hold their block until they see another one? How does that change with
various numbers of remote sensors?
Other applications in the future could very well involve transaction
spread, double spends, network partitions, transaction replacement, etc.
If the simulation run in question involves blocks, I'd like realistic
latencies for blocks. If it is about transactions, the latencies should
be realistic for transactions.
What is realistic for those? That brings me to...
I'll kick in another 1 BTC for an instrumentation package for the
reference client. Same conditions as before. A runtime option,
disabled by default, that collects data for the simulator. If this
creates an uproar, I'll also accept a compile-time option. Support
dumping to a file that can be uploaded to a parser as the bare minimum,
and if you are feeling clever, add automatic uploads to a server
specified in the conf file, or whatever. All data should be anonymous,
of course. Local file should be in a format that humans can read (JSON,
XML, CSV, etc) so that people can verify that the data is indeed anonymous.
I want stats on peers (number, turnover, latency, in/out, etc), stats on
local operations (I/O stats, sigs per second when verifying a block,
fraction of sig cache hits when validating, etc) and whatever else might
be useful to a simulator. Each parameter should collect min, max, mean,
std. deviation, etc so that the simulator can provide realistic virtual
nodes.
Also, I don't want anyone to think that they need to satisfy me
personally to collect on either of these two bounties. I will pay mine
for a product that is generally along the lines I have laid out, if a
couple of the core devs (Gavin, Greg, Jeff, sipa, Luke, etc) agree that
your work is useful.
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
> behaviour.
>
> 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)?
>
> I imagine the latter is pretty useless, beyond specifying that the
> signature/proof of work is valid/invalid.
>
> If we could build up a set of experiments we'd like to run on it, it
> would help clarify what's needed.
>
> Off the top of my head:
>
> - Peter Todd's miner strategy of sending blocks to only 51% of the
> hashpower.
> - Various network split conditions, and how aware of the split nodes
> would be (and the effect of client variability).
> - Testing the feasability of network race double spends, or Finney
> attacks.
> - Various network partition scenarios.
> - Tricking SPV nodes.
>
> On Nov 6, 2013 6:37 AM, "Jeff Garzik" <jgarzik@bitpay.com
> <mailto:jgarzik@bitpay.com>> wrote:
>
> I will contribute 1 BTC to this bounty, under same terms and
> expiration.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming
> models. Explore
> techniques for threading, error checking, porting, and tuning. Get
> the most
> from the latest Intel processors and coprocessors. See abstracts
> and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------030006090905040104020208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">What I want is configurable 1/10/100
millisecond ticks, and accurate flow of information.<br>
<br>
It doesn't seem necessary to really emulate the whole protocol,
nor to be overly concerned with the content of messages, nor to
simulate every little housekeeping step or network message.<br>
<br>
I'm not looking for a bitcoin-network-in-a-bottle, I just want to
see flows. In the current situation, how often does a miner win
if they hold their block until they see another one? How does
that change with various numbers of remote sensors?<br>
<br>
Other applications in the future could very well involve
transaction spread, double spends, network partitions, transaction
replacement, etc.<br>
<br>
If the simulation run in question involves blocks, I'd like
realistic latencies for blocks. If it is about transactions, the
latencies should be realistic for transactions.<br>
<br>
What is realistic for those? That brings me to...<br>
<br>
I'll kick in another 1 BTC for an instrumentation package for the
reference client. Same conditions as before. A runtime option,
disabled by default, that collects data for the simulator. If
this creates an uproar, I'll also accept a compile-time option.
Support dumping to a file that can be uploaded to a parser as the
bare minimum, and if you are feeling clever, add automatic uploads
to a server specified in the conf file, or whatever. All data
should be anonymous, of course. Local file should be in a format
that humans can read (JSON, XML, CSV, etc) so that people can
verify that the data is indeed anonymous.<br>
<br>
I want stats on peers (number, turnover, latency, in/out, etc),
stats on local operations (I/O stats, sigs per second when
verifying a block, fraction of sig cache hits when validating,
etc) and whatever else might be useful to a simulator. Each
parameter should collect min, max, mean, std. deviation, etc so
that the simulator can provide realistic virtual nodes.<br>
<br>
Also, I don't want anyone to think that they need to satisfy me
personally to collect on either of these two bounties. I will pay
mine for a product that is generally along the lines I have laid
out, if a couple of the core devs (Gavin, Greg, Jeff, sipa, Luke,
etc) agree that your work is useful.<br>
<br>
<br>
Christophe Biocca wrote:<br>
</div>
<blockquote
cite="mid:CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<p>I might try building this sometime soon. I think it may also
serve an educational purpose when trying to understand the
whole network's behaviour.</p>
<p>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)?<br>
</p>
<p>I imagine the latter is pretty useless, beyond specifying
that the signature/proof of work is valid/invalid.</p>
<p>If we could build up a set of experiments we'd like to run on
it, it would help clarify what's needed.</p>
<p>Off the top of my head:</p>
<p>- Peter Todd's miner strategy of sending blocks to only 51%
of the hashpower.<br>
- Various network split conditions, and how aware of the split
nodes would be (and the effect of client variability).<br>
- Testing the feasability of network race double spends, or
Finney attacks.<br>
- Various network partition scenarios.<br>
- Tricking SPV nodes.<br>
</p>
<div class="gmail_quote">On Nov 6, 2013 6:37 AM, "Jeff Garzik"
<<a moz-do-not-send="true" href="mailto:jgarzik@bitpay.com"
target="_blank">jgarzik@bitpay.com</a>> wrote:<br
type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>I will contribute 1 BTC to this bounty, under same terms
and expiration.</p>
<br>
------------------------------------------------------------------------------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming
models. Explore<br>
techniques for threading, error checking, porting, and
tuning. Get the most<br>
from the latest Intel processors and coprocessors. See
abstracts and register<br>
<a moz-do-not-send="true"
href="http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk"
target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net"
target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------030006090905040104020208--
|
