Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WalNk-0001Zt-JZ for bitcoin-development@lists.sourceforge.net; Thu, 17 Apr 2014 12:25:32 +0000 Received: from mail-la0-f52.google.com ([209.85.215.52]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WalNj-0007Gd-7C for bitcoin-development@lists.sourceforge.net; Thu, 17 Apr 2014 12:25:32 +0000 Received: by mail-la0-f52.google.com with SMTP id ec20so315425lab.11 for ; Thu, 17 Apr 2014 05:25:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=I7fyDT/PPAr5gn33PZt1WOOwKkPHcK+yzSAH5neUsGY=; b=gXVK2Cp+MsxAgynhSfGlegtu8bM0lp1j0ulprxnvwe8dD5FeFRU/I4elge05qF5Hos Rgp8ZOJQM/Q+QpYxA3xVAL2W9qZOcvtA54hbIvMLQfkFp3kSiWzc4dZBu5C09uDc8+b6 ByXyABQzXhu9cFMhOHWr3I+fUqR1uFNuu644y7v75hN/gyipS2gPWfRg7Fe0Zni2HAbZ SDmJ3Nvxqup4FHt6Vy/c9fcMpOZMsJeH2UD6kaM2Qi4KwdHgw/BOsF6Sqi/AyYNJiNDT fUOKBlYKPPhhMELo2MbdwB/qF4392qshsca1yxnh2kbfEDaQR6+wfKcEwMQPuQOg2OaP BHJQ== X-Gm-Message-State: ALoCoQlTtAwQ5jFWyzcpSll6maj6U5iFV7z6igAf5Lc0a36EgjGMAkkcNDkYGR8Haexh1y5tIkcr MIME-Version: 1.0 X-Received: by 10.152.116.84 with SMTP id ju20mr84431lab.62.1397737524193; Thu, 17 Apr 2014 05:25:24 -0700 (PDT) Received: by 10.112.60.196 with HTTP; Thu, 17 Apr 2014 05:25:24 -0700 (PDT) X-Originating-IP: [85.53.138.195] Date: Thu, 17 Apr 2014 14:25:24 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WalNj-0007Gd-7C Subject: [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 12:25:32 -0000 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/445321928a143cb9a6f56777cbb7479dd3= 2c3bcd 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.org= #private-ledgers https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org= #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. --=20 Jorge Tim=F3n http://freico.in/