From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 27797A49 for ; Wed, 21 Jun 2017 13:24:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7FCDC1CE for ; Wed, 21 Jun 2017 13:24:17 +0000 (UTC) Received: by mail-qt0-f182.google.com with SMTP id f92so17914947qtb.2 for ; Wed, 21 Jun 2017 06:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=p8S++qeiJyT1xdEnPaMAJN0feVK2e2+CetejixR8sHQ=; b=E6PdUmwiVB/qGzSbr9fMQYppYOb9fplxAsfe3V+niBUG7n7LQ+7UZ3fGSsy5VYd87+ izNoAtuQ6J2nNmPktc6SIQnyEdSebsEl1k8ld6j5a5iL0FURuGPiC5FEninJVsFhf5b0 7Oexf7tV/UgT4/yJAB0GzBszY23uobnihn5kjN990IkL3+sr/2jyQutskCuPExJwrFVr ypEIAG94XK2nQUNam8OxlGvqnLcGpB/cSUbhT7iXxHZ8LpERhdDjEK4UiOi8uvHfTfeD VZWJRoTeskeMCGmqztVsv0ByR6RYcshBrJEMYP2Gu1dd5KT/0pfCPImUfzvugwxTRZ4J Mrcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=p8S++qeiJyT1xdEnPaMAJN0feVK2e2+CetejixR8sHQ=; b=a8Oxp+72WUxoSxH+ooGs7MFWKeFovj0uvlGV/GnGV0ufGUcaaDpWiuqJn5jCHT56dA QWK6Da5vihFBu4eYYbxqerDYN5ffzHGiAWR6AXh6m47n0r1UGWjYoXF6odgmLBCvfegJ RSDkyR2eU5r3nUm1AIxzyUlSyfnc+/lhuRLs8zZkzwNitV/U3yJP744qUKneWz9t2JWn sORx/r3QIwhVz67epdk9gDNNRsCJQCJMbLL9vxZsGHzwSndmF9U5kbIhvhkLqMVXMHpG 68YH4GTNigDfQXWrGZVHhirLrVSOqDPCIQ7h+rp0rA6KtsilutDA+Hl1RVtCogJ8mBG4 fZzA== X-Gm-Message-State: AKS2vOwLqTSLNXNir2peGbUeVYklYYqUnAB6VEg9ZcgqDVux6hGrUZjV KqV/Lc7DEU7yGVsJ X-Received: by 10.237.32.202 with SMTP id 68mr42518530qtb.128.1498051456353; Wed, 21 Jun 2017 06:24:16 -0700 (PDT) Received: from HEDWIG.INI.CMU.EDU (HEDWIG.INI.CMU.EDU. [128.2.16.51]) by smtp.gmail.com with ESMTPSA id m129sm10115286qkc.2.2017.06.21.06.24.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 06:24:15 -0700 (PDT) Date: Wed, 21 Jun 2017 09:24:09 -0400 From: "Gabriel L. Somlo" 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 X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 21 Jun 2017 13:47:33 +0000 Subject: [bitcoin-dev] RFC: Sandboxed Bitcoin network ? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:24:18 -0000 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(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