path: root/52/d9bb1729e7fab98051121394f7d0e8213749e9

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <brianchoffman@gmail.com>) id 1WanRo-0008A3-D7
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Apr 2014 14:37:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.42 as permitted sender)
	client-ip=209.85.160.42; envelope-from=brianchoffman@gmail.com;
	helo=mail-pb0-f42.google.com; 
Received: from mail-pb0-f42.google.com ([209.85.160.42])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WanRn-0001k3-4j
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Apr 2014 14:37:52 +0000
Received: by mail-pb0-f42.google.com with SMTP id rr13so450132pbb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 17 Apr 2014 07:37:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.136.226 with SMTP id qd2mr16193585pbb.72.1397745465175;
	Thu, 17 Apr 2014 07:37:45 -0700 (PDT)
Received: by 10.70.89.237 with HTTP; Thu, 17 Apr 2014 07:37:45 -0700 (PDT)
In-Reply-To: <CAC1+kJMrpx0tyE8d0wkwjBthhSPMCdr=9LrJHQFTF4G1vg4MAg@mail.gmail.com>
References: <CAC1+kJMrpx0tyE8d0wkwjBthhSPMCdr=9LrJHQFTF4G1vg4MAg@mail.gmail.com>
Date: Thu, 17 Apr 2014 10:37:45 -0400
Message-ID: <CAADm4BAFSrEp1aHaS1LgZMJ7-fDhYRJ1ndZDYK8hfmJ+a7iBFg@mail.gmail.com>
From: Brian Hoffman <brianchoffman@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@monetize.io>
Content-Type: multipart/alternative; boundary=e89a8f234a39f036a004f73df917
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(brianchoffman[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WanRn-0001k3-4j
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Timed testing
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, 17 Apr 2014 14:37:52 -0000

--e89a8f234a39f036a004f73df917
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"So my question to the community is, how invasive is this to bitcoin's
source code?"

I'd say not very considering you have regression testing mode.


On Thu, Apr 17, 2014 at 8:25 AM, Jorge Tim=C3=B3n <jtimon@monetize.io> wrot=
e:

> I'm implementing a new testing mode that produces blocks
> periodically. You can get what I have so far here:
>
> https://github.com/jtimon/bitcoin/tree/timed
>
> It depends on pull request #3824 with some improvements on
> CChainParams, but after that the changes required to add this new
> mode are very small:
>
>
> https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f56777cbb7479d=
d32c3bcd
>
> I guess I need a new genesis block, different magic numbers, etc. So
> this is definitely not ready.
> You can run it like this:
>
> bitcoind -timedtest -gen=3D1 blocktime=3D2000
>
> blocktime defaults to 1000 milliseconds for timedtest mode and 0 for
> the rest of the modes.
>
> What could this testing mode be useful for?
>
> Basically, simulations.
> For example, you could run several nodes implementing different mining
> policies. Let's say I want to mine 50% of the blocks with standard policy=
,
> 25% with policy A and 25% with policy B. I can run 1 one for each of
> one with block times 2000, 1000 and 1000 respectively.
>
> Maybe I want to detect performance bottlenecks by stressing this mode
> with as many transaction as can be processed, maybe removing the
> block size limits in the simulations.
>
> But this still doesn't serve for hardfork or double-spend attacks
> simulations without calculating any pow, which would be another
> interesting feature for a new testing mode.
> I would like to implement the new mode following as the concept of
> private chains described in freimarkets:
>
> http://freico.in/docs/freimarkets.pdf
>
> https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.o=
rg#private-ledgers
>
> https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.o=
rg#off-chain-transactions
>
> I know this could be considered a "non-bitcoinish" application and
> therefore be controversial as discussed in PR 3824, so I want to keep
> the conversation focused on testing use cases useful to bitcoin itself
> only: additional changes can be implemented elsewhere.
> One way I think you could support chain races simulations by using a
> private mode could be the following:
>
> 1) The private mode works like the timed mode in how often it
>    produces blocks.
>
> 2) In private mode you replace the pow-related fields with a
>    blockPubkeyScript and a lastBlockSigScript fields. In the genesis
>    block, lastBlockSigScript is empty and the initial
>    blockPubkeyScript can be an optional parameter like blocktime. You
>    can set any valid script, probably p2sh, maybe with multisig to
>    allow different nodes to sign.
>
> 3) In this context, longer chains mean "more work". Another way to
>    see it is that all blocks just contain work=3D=3D1 in them.
>
> So let's say we want to simulate an attack using 50% standard and 50%
> attacker blocks. You set up the private mode script to be a 1 of 2
> multisig and make each node sign always with the same private key
> (maybe an additional parameter).
> You make the attacker reject any blocks from height X that he hasn't
> signed himself to get the result you wanted: the standard node will
> produce blocks on top of the longest chain while the attacker will
> only hash on top of his own blocks.
>
> So my question to the community is, how invasive is this to bitcoin's
> source code?
> In my opinion, done properly could actually result (apart from getting
> the new features) in more readable code, not less, since you will
> probably need to make sure proof of work functionality is properly
> encapsulated during the implementation process (see PR 3839 for a first
> step on that direction).
> But, should I push a private mode to the core or just the timed one
> and implement the private mode elsewhere?
>
> Of course other comments on the parameters, defaults or any other
> design or implementation details are also welcomed.
>
> --
> Jorge Tim=C3=B3n
>
> http://freico.in/
>
>
> -------------------------------------------------------------------------=
-----
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and thei=
r
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--e89a8f234a39f036a004f73df917
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;<span style=3D"font-family:arial,sans-serif;font-siz=
e:13px">So my question to the community is, how invasive is this to bitcoin=
&#39;s</span><br style=3D"font-family:arial,sans-serif;font-size:13px"><spa=
n style=3D"font-family:arial,sans-serif;font-size:13px">source code?&quot;<=
/span><div>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">I&#39;d =
say not very considering you have regression testing mode.</span></div></di=
v>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Apr 1=
7, 2014 at 8:25 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:jtimon@monetize.io" target=3D"_blank">jtimon@monetize.io</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
I&#39;m implementing a new testing mode that produces blocks<br>
periodically. You can get what I have so far here:<br>
<br>
<a href=3D"https://github.com/jtimon/bitcoin/tree/timed" target=3D"_blank">=
https://github.com/jtimon/bitcoin/tree/timed</a><br>
<br>
It depends on pull request #3824 with some improvements on<br>
CChainParams, but after that the changes required to add this new<br>
mode are very small:<br>
<br>
<a href=3D"https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f5677=
7cbb7479dd32c3bcd" target=3D"_blank">https://github.com/jtimon/bitcoin/comm=
it/445321928a143cb9a6f56777cbb7479dd32c3bcd</a><br>
<br>
I guess I need a new genesis block, different magic numbers, etc. So<br>
this is definitely not ready.<br>
You can run it like this:<br>
<br>
bitcoind -timedtest -gen=3D1 blocktime=3D2000<br>
<br>
blocktime defaults to 1000 milliseconds for timedtest mode and 0 for<br>
the rest of the modes.<br>
<br>
What could this testing mode be useful for?<br>
<br>
Basically, simulations.<br>
For example, you could run several nodes implementing different mining<br>
policies. Let&#39;s say I want to mine 50% of the blocks with standard poli=
cy,<br>
25% with policy A and 25% with policy B. I can run 1 one for each of<br>
one with block times 2000, 1000 and 1000 respectively.<br>
<br>
Maybe I want to detect performance bottlenecks by stressing this mode<br>
with as many transaction as can be processed, maybe removing the<br>
block size limits in the simulations.<br>
<br>
But this still doesn&#39;t serve for hardfork or double-spend attacks<br>
simulations without calculating any pow, which would be another<br>
interesting feature for a new testing mode.<br>
I would like to implement the new mode following as the concept of<br>
private chains described in freimarkets:<br>
<br>
<a href=3D"http://freico.in/docs/freimarkets.pdf" target=3D"_blank">http://=
freico.in/docs/freimarkets.pdf</a><br>
<a href=3D"https://github.com/jtimon/freimarkets/blob/master/doc/freimarket=
s_specs.org#private-ledgers" target=3D"_blank">https://github.com/jtimon/fr=
eimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers</a><br>
<a href=3D"https://github.com/jtimon/freimarkets/blob/master/doc/freimarket=
s_specs.org#off-chain-transactions" target=3D"_blank">https://github.com/jt=
imon/freimarkets/blob/master/doc/freimarkets_specs.org#off-chain-transactio=
ns</a><br>

<br>
I know this could be considered a &quot;non-bitcoinish&quot; application an=
d<br>
therefore be controversial as discussed in PR 3824, so I want to keep<br>
the conversation focused on testing use cases useful to bitcoin itself<br>
only: additional changes can be implemented elsewhere.<br>
One way I think you could support chain races simulations by using a<br>
private mode could be the following:<br>
<br>
1) The private mode works like the timed mode in how often it<br>
=C2=A0 =C2=A0produces blocks.<br>
<br>
2) In private mode you replace the pow-related fields with a<br>
=C2=A0 =C2=A0blockPubkeyScript and a lastBlockSigScript fields. In the gene=
sis<br>
=C2=A0 =C2=A0block, lastBlockSigScript is empty and the initial<br>
=C2=A0 =C2=A0blockPubkeyScript can be an optional parameter like blocktime.=
 You<br>
=C2=A0 =C2=A0can set any valid script, probably p2sh, maybe with multisig t=
o<br>
=C2=A0 =C2=A0allow different nodes to sign.<br>
<br>
3) In this context, longer chains mean &quot;more work&quot;. Another way t=
o<br>
=C2=A0 =C2=A0see it is that all blocks just contain work=3D=3D1 in them.<br=
>
<br>
So let&#39;s say we want to simulate an attack using 50% standard and 50%<b=
r>
attacker blocks. You set up the private mode script to be a 1 of 2<br>
multisig and make each node sign always with the same private key<br>
(maybe an additional parameter).<br>
You make the attacker reject any blocks from height X that he hasn&#39;t<br=
>
signed himself to get the result you wanted: the standard node will<br>
produce blocks on top of the longest chain while the attacker will<br>
only hash on top of his own blocks.<br>
<br>
So my question to the community is, how invasive is this to bitcoin&#39;s<b=
r>
source code?<br>
In my opinion, done properly could actually result (apart from getting<br>
the new features) in more readable code, not less, since you will<br>
probably need to make sure proof of work functionality is properly<br>
encapsulated during the implementation process (see PR 3839 for a first<br>
step on that direction).<br>
But, should I push a private mode to the core or just the timed one<br>
and implement the private mode elsewhere?<br>
<br>
Of course other comments on the parameters, defaults or any other<br>
design or implementation details are also welcomed.<br>
<br>
--<br>
Jorge Tim=C3=B3n<br>
<br>
<a href=3D"http://freico.in/" target=3D"_blank">http://freico.in/</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/NeoTech" target=3D"_blank">http://p.sf.net/s=
fu/NeoTech</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--e89a8f234a39f036a004f73df917--