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)
Subject: Re: [Bitcoin-development] we can all relax now
Precedence: list

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.&nbsp; In the current situation, how often does a miner win
      if they hold their block until they see another one?&nbsp; 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.&nbsp; If it is about transactions, the
      latencies should be realistic for transactions.<br>
      <br>
      What is realistic for those?&nbsp; That brings me to...<br>
      <br>
      I'll kick in another 1 BTC for an instrumentation package for the
      reference client.&nbsp; Same conditions as before.&nbsp; A runtime option,
      disabled by default, that collects data for the simulator.&nbsp; If
      this creates an uproar, I'll also accept a compile-time option.&nbsp;
      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.&nbsp; All data
      should be anonymous, of course.&nbsp; 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.&nbsp; 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.&nbsp; 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"
          &lt;<a moz-do-not-send="true" href="mailto:jgarzik@bitpay.com"
            target="_blank">jgarzik@bitpay.com</a>&gt; 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&amp;iu=/4140/ostg.clktrk"
              target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=60136231&amp;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&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=60136231&amp;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--