From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ue3ar-0007dH-OC for bitcoin-development@lists.sourceforge.net; Sun, 19 May 2013 13:24:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.53 as permitted sender) client-ip=209.85.160.53; envelope-from=adam.back@gmail.com; helo=mail-pb0-f53.google.com; Received: from mail-pb0-f53.google.com ([209.85.160.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ue3aq-0006tK-MF for bitcoin-development@lists.sourceforge.net; Sun, 19 May 2013 13:24:09 +0000 Received: by mail-pb0-f53.google.com with SMTP id un4so99927pbc.12 for ; Sun, 19 May 2013 06:24:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent:x-hashcash:x-hashcash; bh=8ZdFqhM3WMm7PqcbZ8x1VgMMoslwgbDWx8Dr7X6jiFM=; b=V+y0TVbVQAn3LhCZq51An6mBaqDl+3TSAXTJsljxBv0yVaKVfH53z4aJ/soDamMw7b ciK2ILqsGPpbqo9A022B8/oH4uHT8lLz54QAUF53w30Wthna7WnAH+lXufcjW+Vkd/JJ XotlNpNkJOr2QTu8S7TBbiTHgIqrM+6inGd63OHTpuYoCmVObwqzh1e72p2BW5CnM8f5 lOZsyS84xpiOBfRAIgh6Z9/9Ixk6z3MOEy+DP40zMPvu9ue66XiSqBhQYFVq41BHP8g2 tj/XmA7C4nHMOKUtd8TAGjxjFy0K44Z1w3FY33ATourU5Va2I39rsIgLK58/bjEjeQfa JwPg== X-Received: by 10.66.144.5 with SMTP id si5mr57262160pab.6.1368969842804; Sun, 19 May 2013 06:24:02 -0700 (PDT) Received: from netbook (63-145-238-4.dia.static.qwest.net. [63.145.238.4]) by mx.google.com with ESMTPSA id v7sm19698883pbq.32.2013.05.19.06.24.01 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 06:24:02 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 2C5D02E0743; Sun, 19 May 2013 15:24:01 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Sun, 19 May 2013 15:23:59 +0200 Date: Sun, 19 May 2013 15:23:59 +0200 From: Adam Back To: Bitcoin-Dev Message-ID: <20130519132359.GA12366@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:130519:bitcoin-development@lists.sourceforge.net::Q7ScMWlOc73AA fbs:000000000000000000007ehg X-Hashcash: 1:20:130519:adam@cypherspace.org::r5CBgzZiKmDEUqAb:00000000000000000 0000000000000000000000000uiv X-Spam-Score: -1.5 (-) 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 (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Ue3aq-0006tK-MF Subject: [Bitcoin-development] is there a way to do bitcoin-staging? 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: Sun, 19 May 2013 13:24:09 -0000 Is there a way to experiment with new features - eg committed coins - that doesnt involve an altcoin in the conventional sense, and also doesnt impose a big testing burden on bitcoin main which is a security and testing risk? eg lets say some form of merged mine where an alt-coin lets call it bitcoin-staging? where the coins are the same coins as on bitcoin, the mining power goes to bitcoin main, so some aspect of merged mining, but no native mining. and ability to use bitcoins by locking them on bitcoin to move them to bitcoin-staging and vice versa (ie exchange them 1:1 cryptographically, no exchange). Did anyone figure anything like that out? Seems vaguely doable and maybe productive. The only people with coins at risk of defects in a new feature, or insufficiently well tested novel feature are people with coins on bitcoin-staging. Yes I know about bitcoin-test this is not it. I mean a real live system, with live value, but that is intentionally wanting to avoid forking bitcoins parameters, nor value, nor mindshare dillution. In this way something potentially interesting could move forward faster, and be les risky to the main bitcoin network. eg particularly defenses against It might also be a more real world test test (after bitcoin-test) because some parameters are different on test, and some issues may not manifest without more real activity. Then also bitcoin could cherry pick interesting patches and merge them after extensive real-world validation with real-money at stake (by early adopters). Adam