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 ) 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 ; 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: References: Date: Thu, 17 Apr 2014 10:37:45 -0400 Message-ID: From: Brian Hoffman To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= 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 Subject: Re: [Bitcoin-development] Timed testing X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
"So my question to the community is, how invasive is this to bitcoin= 's
source code?"<= /span>

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


On Thu, Apr 1= 7, 2014 at 8:25 AM, Jorge Tim=C3=B3n <jtimon@monetize.io> w= rote:
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/comm= it/445321928a143cb9a6f56777cbb7479dd32c3bcd

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 poli= cy,
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/fr= eimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers
https://github.com/jt= imon/freimarkets/blob/master/doc/freimarkets_specs.org#off-chain-transactio= ns

I know this could be considered a "non-bitcoinish" application an= d
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
=C2=A0 =C2=A0produces blocks.

2) In private mode you replace the pow-related fields with a
=C2=A0 =C2=A0blockPubkeyScript and a lastBlockSigScript fields. In the gene= sis
=C2=A0 =C2=A0block, lastBlockSigScript is empty and the initial
=C2=A0 =C2=A0blockPubkeyScript can be an optional parameter like blocktime.= You
=C2=A0 =C2=A0can set any valid script, probably p2sh, maybe with multisig t= o
=C2=A0 =C2=A0allow different nodes to sign.

3) In this context, longer chains mean "more work". Another way t= o
=C2=A0 =C2=A0see 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 their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/s= fu/NeoTech
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--e89a8f234a39f036a004f73df917--