Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UeJfm-0005ar-LW for bitcoin-development@lists.sourceforge.net; Mon, 20 May 2013 06:34:18 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.49 as permitted sender) client-ip=209.85.160.49; envelope-from=etotheipi@gmail.com; helo=mail-pb0-f49.google.com; Received: from mail-pb0-f49.google.com ([209.85.160.49]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UeJfl-0004jK-25 for bitcoin-development@lists.sourceforge.net; Mon, 20 May 2013 06:34:18 +0000 Received: by mail-pb0-f49.google.com with SMTP id rp8so3795576pbb.36 for ; Sun, 19 May 2013 23:34:11 -0700 (PDT) X-Received: by 10.66.12.40 with SMTP id v8mr59859787pab.13.1369031651150; Sun, 19 May 2013 23:34:11 -0700 (PDT) Received: from [192.168.6.14] (ip-64-134-225-21.public.wayport.net. [64.134.225.21]) by mx.google.com with ESMTPSA id zy5sm22740554pbb.43.2013.05.19.23.34.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 23:34:10 -0700 (PDT) Message-ID: <5199C3DE.901@gmail.com> Date: Mon, 20 May 2013 02:34:06 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20130519132359.GA12366@netbook.cypherspace.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070502010301040004020702" 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 (etotheipi[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: 1UeJfl-0004jK-25 Subject: Re: [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: Mon, 20 May 2013 06:34:18 -0000 This is a multi-part message in MIME format. --------------070502010301040004020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is exactly what I was planning to do with the inappropriately-named "Ultimate Blockchain Compression ". I wanted to reorganize the blockchain data into an authenticated tree, indexed by TxOut script (address), instead of tx-hash. Much like a regular merkle tree, you can store the root in the block header, and communicate branches of that tree to nodes, to prove inclusion (and exclusion!) of TxOuts for any given script/address. Additionally, you can include at each node, the sum of BTC in all nodes below it, which offers some other nice benefits. I think this idea is has epic upside-potential for bitcoin if it works -- even "SPV" nodes could query their unspent TxOut list for their wallet from any untrusted peer and compare the result directly to the blockheaders/POW. Given nothing but the headers, you can verify the balance of 100 addresses with 250 kB. But also epic failure-potential in terms of feasibility and cost-to-benefit for miners. For it to really work, it's gotta be part of the mainnet validation rules, but no way it can be evaluated realistically without some kind of "staging". Therefore, I had proposed that this be merge-mined on a "meta-chain" first...get a bunch of miners on board to agree to merge mine and see it in action. It seemed like a perfectly non-disruptive way to prove out a particular idea before we actually consider making a protocol change that significant. Even if it stayed on its own meta chain, as long as there is some significant amount of hashpower working on it, it can still be a useful tool. Unfortunately, my experience with merged mining is minimal, so I'm still not clear how feasible/reliable it is as an alternative to direct blockchain integration. That's a discussion I'd like to have. -Alan On 5/19/2013 11:08 AM, Peter Vessenes wrote: > I think this is a very interesting idea. As Bitcoiners, we often stuff > things into the 'alt chain' bucket in our heads; I wonder if this idea > works better as a curing period, essentially an extended version of > the current 100 block wait for mined coins. > > An alternate setup comes to mind; I can imagine this working as a sort > of gift economy; people pay real BTC for merge-mined "beta BTC" as a > way to support development. There is no doubt a more elegant and > practical solution that might have different economic and crypto > characteristics. > > > > On Sun, May 19, 2013 at 6:23 AM, Adam Back > wrote: > > 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 > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers > complete > security visibility with the essential security capabilities. > Easily and > efficiently configure, manage, and operate all of your security > controls > from a single console and one unified framework. Download a free > trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > -- > Are you coming to Bitcoin2013 in San Jose In > May? > ------------------------------------------------------------------------ > > CoinLab LogoPETER VESSENES > CEO > > *peter@coinlab.com * / 206.486.6856 / > SKYPE: vessenes > 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104 > > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------070502010301040004020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This is exactly what I was planning to do with the inappropriately-named "Ultimate Blockchain Compression".  I wanted to reorganize the blockchain data into an authenticated tree, indexed by TxOut script (address), instead of tx-hash.  Much like a regular merkle tree, you can store the root in the block header, and communicate branches of that tree to nodes, to prove inclusion (and exclusion!) of TxOuts for any given script/address.  Additionally, you can include at each node, the sum of BTC in all nodes below it, which offers some other nice benefits.

I think this idea is has epic upside-potential for bitcoin if it works -- even "SPV" nodes could query their unspent TxOut list for their wallet from any untrusted peer and compare the result directly to the blockheaders/POW.  Given nothing but the headers, you can verify the balance of 100 addresses with 250 kB.  But also epic failure-potential in terms of feasibility and cost-to-benefit for miners.  For it to really work, it's gotta be part of the mainnet validation rules, but no way it can be evaluated realistically without some kind of "staging".  Therefore, I had proposed that this be merge-mined on a "meta-chain" first...get a bunch of miners on board to agree to merge mine and see it in action.  It seemed like a perfectly non-disruptive way to prove out a particular idea before we actually consider making a protocol change that significant.  Even if it stayed on its own meta chain, as long as there is some significant amount of hashpower working on it, it can still be a useful tool. 

Unfortunately, my experience with merged mining is minimal, so I'm still not clear how feasible/reliable it is as an alternative to direct blockchain integration.  That's a discussion I'd like to have.

-Alan


On 5/19/2013 11:08 AM, Peter Vessenes wrote:
I think this is a very interesting idea. As Bitcoiners, we often stuff things into the 'alt chain' bucket in our heads; I wonder if this idea works better as a curing period, essentially an extended version of the current 100 block wait for mined coins.

An alternate setup comes to mind; I can imagine this working as a sort of gift economy; people pay real BTC for merge-mined "beta BTC" as a way to support development. There is no doubt a more elegant and practical solution that might have different economic and crypto characteristics.



On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org> wrote:
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

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Are you coming to Bitcoin2013 in San Jose In May? 

CoinLab LogoPETER VESSENES 
CEO

peter@coinlab.com  /  206.486.6856  / SKYPE: vessenes 
71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------070502010301040004020702--