Date: Wed, 21 Jun 2017 09:24:09 -0400
From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170621132408.GA29456@HEDWIG.INI.CMU.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.8.0 (2017-02-23)
Subject: [bitcoin-dev] RFC: Sandboxed Bitcoin network ?
Precedence: list

I've been looking for a way to set up a self-contained, sandboxed
network of Bitcoin peer nodes, for testing and experimentation. Think
a bunch of networked VMs, or containers inside a network simulator
like GNS3 (http://gns3.com) or CORE (http://github.com/coreemu/core).

Neither 'main' nor 'test' are feasible, due to hard-coded assumptions
they both make about their respective publicly shared blockchain state.

Right now, that leaves 'regtest' -- however, connecting peers together
over the sandboxed network in regtest mode is a manual process.

After some tinkering, the following changes make 'regtest' behave
similarly to "the real thing", but inside an isolated sandbox network:

diff --git a/src/chainparams.cpp b/src/chainparams.cpp
index 3b42c5f..4345667 100644
--- a/src/chainparams.cpp
+++ b/src/chainparams.cpp
@@ -275,7 +275,7 @@ public:
         consensus.nPowTargetTimespan = 14 * 24 * 60 * 60; // two weeks
         consensus.nPowTargetSpacing = 10 * 60;
         consensus.fPowAllowMinDifficultyBlocks = true;
-        consensus.fPowNoRetargeting = true;
+        consensus.fPowNoRetargeting = false;
         consensus.nRuleChangeActivationThreshold = 108; // 75% for testchains
         consensus.nMinerConfirmationWindow = 144; // Faster than normal for regtest (144 instead of 2016)
         consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
@@ -307,11 +307,13 @@ public:
         assert(genesis.hashMerkleRoot == uint256S("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"));
 
         vFixedSeeds.clear(); //!< Regtest mode doesn't have any fixed seeds.
+        vFixedSeeds = std::vector<SeedSpec6>(pnSeed6_regtest, pnSeed6_regtest + ARRAYLEN(pnSeed6_regtest));
         vSeeds.clear();      //!< Regtest mode doesn't have any DNS seeds.
+        vSeeds.push_back(CDNSSeedData("btc-sandbox.local", "seed.btc-sandbox.local"));
 
-        fDefaultConsistencyChecks = true;
+        fDefaultConsistencyChecks = false;
         fRequireStandard = false;
-        fMineBlocksOnDemand = true;
+        fMineBlocksOnDemand = false;
 
         checkpointData = (CCheckpointData) {
             {

(not showing the pnSeed6_regtest[] table added to src/chainparamsseeds.h)

Additionally, for this network to behave realistically, I need peers to
actually mine blocks on their own once connected together, so I reverted 
commit 8d1de43 and re-added the 'setgenerate' triggered internal miner.

At this point, I have a few questions for the Bitcoin dev community:

  1. would a realistic sandbox test mode be interesting enough to make
     it worth supporting upstream? (happy to submit patches and do
     revisions if there's interest, and a chance for success)

  2. if yes, support modifying 'regtest' mode accordingly via some sort of
     command line flags, or rather implement a dedicated 'sandbox' mode
     with its own CChainParams defaults?

  3. finally, would re-inserting the internal 'setgenerate' miner be a
     deal breaker?

Any other thoughts and comments also much appreciated!

Thanks much,
--Gabriel