Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.45 as permitted sender)
	client-ip=209.85.215.45; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f45.google.com; 
MIME-Version: 1.0
In-Reply-To: <20131014180807.GA32082@netbook.cypherspace.org>
References: <20130519132359.GA12366@netbook.cypherspace.org>
	<CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com>
	<5199C3DE.901@gmail.com>
	<20131014180807.GA32082@netbook.cypherspace.org>
Date: Thu, 21 Nov 2013 21:35:44 +0100
Message-ID: <CAKaEYhJVLhRfcX7T62S8fx+cPKJepQCd4gBnqv5cUJzcGM7MHA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=047d7b3a84c286c05404ebb5d728
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Precedence: list

--047d7b3a84c286c05404ebb5d728
Content-Type: text/plain; charset=ISO-8859-1

On 14 October 2013 20:08, Adam Back <adam@cypherspace.org> wrote:

> Coming back to the staging idea, maybe this is a realistic model that could
> work.  The objective being to provide a way for bitcoin to move to a live
> beta and stable being worked on in parallel like fedora vs RHEL or odd/even
> linux kernel versions.
>
> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
> stable and leap-frogs as beta becomes stable after testing.
>
> Its a live beta, meaning real value, real contracts.  But we dont want it
> to
> be an alt-coin with a floating value exactly, we want it to be bitcoin, but
> the bleeding edge bitcoin so we want to respect the 21 million coin limit,
> and allow coins to move between bitcoin and betacoin with some necessary
> security related restrictions.
>
> There is no mining reward on the betacoin network (can be merge mined for
> security), and the way you opt to move a bitcoin into the betacoin network
> is to mark it as transferred in some UTXO recognized way.  It cant be
> reanimated, its dead.  (eg spend to a specific recognized invalid address
> on
> the bitcoin network).  In this way its not really a destruction, but a
> move,
> moving the coin from bitcoin to betacoin network.
>
> This respects the 21 million coin cap, and avoids betacoin bugs flowing
> back
> and affecting bitcoin security or value-store properties.  Users may buy or
> swap betacoin for bitcoin to facilitate moving money back from betacoin to
> bitcoin.  However that is market priced so the bitcoin network is security
> insulated from beta.  A significant security bug in beta would cause a
> market freeze, until it is rectified.
>
> The cost of a betacoin is capped at one BTC because no one will pay more
> than one bitcoin for a betacoin because they could alternatively move their
> own coin.  The reverse is market priced.
>
> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
> bitcoins can be moved, and the old network switched off, with mining past a
> flag day moving to the betacoin.
>
> During the beta period betacoin is NOT an alpha, people can rely on it and
> use it in anger for real value transactions.  eg if it enables more script
> features, or coin coloring, scalabity tweaks etc people can use it.
> Probably for large value store they are always going to prefer
> bitcoin-stable, but applications that need the coloring features, or
> advanced scripting etc can go ahead and beta.
>
> Bitcoin-stable may pull validated changes and merge them, as a way to pull
> in any features needed in the shorter term and benefit from the betacoin
> validation.  (Testing isnt as much validation as real-money at stake
> survivability).
>
> The arguments are I think that:
>
> - it allows faster development allowing bitcoin to progress features
> faster,
>
> - it avoids mindshare dilution if alternatively an alt-coin with a hit
>    missing feature takes off;
>
> - it concentrates such useful-feature alt activities into one OPEN source
>    and OPEN control foundation mediated area (rather than suspected land
>    grabs on colored fees or such like bitcoin respun as a business model
>    things),
>
> - maybe gets the developers that would've been working on their pet
>    alt-coin, or their startup alt-coin to work together putting more
>    developers, testers and resources onto something with open control (open
>    source does not necessarily mean that much) and bitcoin mindshare
>    branding, its STILL bitcoin, its just the beta network.
>
> - it respects the 21 million limit, starting new mining races probably
>    dillutes the artificial scarcity semantic
>
> - while insulating bitcoin from betacoin security defects (I dont mean
>    betacoin as a testnet, it should have prudent rigorous testing like
>    bitcoin, just the very act of adding a feature creates risk that bitcoin
>    stable can be hesitant to take).
>
> Probably the main issue as always is more (trustable) very high caliber
> testers and developers.  Maybe if the alt-coin minded startups and
> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
> bits they are missing, we'll get more hands to work on something of
> reusable
> value to humanity, in parallel with their startup's objectives and as a way
> for them to get their needed features, while giving back to the bitcoin
> community, and helping bitcoin progress faster.
>
> Maybe bitcoin foundation could ask for BTC donations to hire more
> developers
> and testers full time.  $1.5b of stored value should be interested to safe
> guard their value store, and develop the transaction features.
>

I think there may be a simpler way to do this.

Create a new genesis block for a staging network, but in all other aspects,
as far as possible, keep the properties the same as bitcoin.

Do not actively be opposed to it being traded, but people need to know
that, although there is no intention to reset the chain, new and
potentially not fully tested, changes can be rolled into the network.
Anyone mining staging coins should be prepared for the value to go to zero.

Perhaps also a "straw poll" voting system could be set up for those that
own staging coins could sign messages saying which patches they would like
to test out next.  When patches are stable in the staging area, they could
be "promoted" to the main net ...


>
> Adam
>
> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> >   This is exactly what I was planning to do with the
> >   inappropriately-named "Ultimate Blockchain Compression".  [...]
> >
> >   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".
>
> >   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.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--047d7b3a84c286c05404ebb5d728
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 October 2013 20:08, Adam Back <span dir=3D"ltr">&lt;<a href=
=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Coming back to the staging idea, maybe this =
is a realistic model that could<br>
work. =A0The objective being to provide a way for bitcoin to move to a live=
<br>
beta and stable being worked on in parallel like fedora vs RHEL or odd/even=
<br>
linux kernel versions.<br>
<br>
Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x=
<br>
stable and leap-frogs as beta becomes stable after testing.<br>
<br>
Its a live beta, meaning real value, real contracts. =A0But we dont want it=
 to<br>
be an alt-coin with a floating value exactly, we want it to be bitcoin, but=
<br>
the bleeding edge bitcoin so we want to respect the 21 million coin limit,<=
br>
and allow coins to move between bitcoin and betacoin with some necessary<br=
>
security related restrictions.<br>
<br>
There is no mining reward on the betacoin network (can be merge mined for<b=
r>
security), and the way you opt to move a bitcoin into the betacoin network<=
br>
is to mark it as transferred in some UTXO recognized way. =A0It cant be<br>
reanimated, its dead. =A0(eg spend to a specific recognized invalid address=
 on<br>
the bitcoin network). =A0In this way its not really a destruction, but a mo=
ve,<br>
moving the coin from bitcoin to betacoin network.<br>
<br>
This respects the 21 million coin cap, and avoids betacoin bugs flowing bac=
k<br>
and affecting bitcoin security or value-store properties. =A0Users may buy =
or<br>
swap betacoin for bitcoin to facilitate moving money back from betacoin to<=
br>
bitcoin. =A0However that is market priced so the bitcoin network is securit=
y<br>
insulated from beta. =A0A significant security bug in beta would cause a<br=
>
market freeze, until it is rectified.<br>
<br>
The cost of a betacoin is capped at one BTC because no one will pay more<br=
>
than one bitcoin for a betacoin because they could alternatively move their=
<br>
own coin. =A0The reverse is market priced.<br>
<br>
Once bitcoin beta stabalizes, eg say year or two type of time-frame, a<br>
decision is reached to promote 1.0 beta to 2.0 stable, the remaining<br>
bitcoins can be moved, and the old network switched off, with mining past a=
<br>
flag day moving to the betacoin.<br>
<br>
During the beta period betacoin is NOT an alpha, people can rely on it and<=
br>
use it in anger for real value transactions. =A0eg if it enables more scrip=
t<br>
features, or coin coloring, scalabity tweaks etc people can use it.<br>
Probably for large value store they are always going to prefer<br>
bitcoin-stable, but applications that need the coloring features, or<br>
advanced scripting etc can go ahead and beta.<br>
<br>
Bitcoin-stable may pull validated changes and merge them, as a way to pull<=
br>
in any features needed in the shorter term and benefit from the betacoin<br=
>
validation. =A0(Testing isnt as much validation as real-money at stake<br>
survivability).<br>
<br>
The arguments are I think that:<br>
<br>
- it allows faster development allowing bitcoin to progress features faster=
,<br>
<br>
- it avoids mindshare dilution if alternatively an alt-coin with a hit<br>
=A0 =A0missing feature takes off;<br>
<br>
- it concentrates such useful-feature alt activities into one OPEN source<b=
r>
=A0 =A0and OPEN control foundation mediated area (rather than suspected lan=
d<br>
=A0 =A0grabs on colored fees or such like bitcoin respun as a business mode=
l<br>
=A0 =A0things),<br>
<br>
- maybe gets the developers that would&#39;ve been working on their pet<br>
=A0 =A0alt-coin, or their startup alt-coin to work together putting more<br=
>
=A0 =A0developers, testers and resources onto something with open control (=
open<br>
=A0 =A0source does not necessarily mean that much) and bitcoin mindshare<br=
>
=A0 =A0branding, its STILL bitcoin, its just the beta network.<br>
<br>
- it respects the 21 million limit, starting new mining races probably<br>
=A0 =A0dillutes the artificial scarcity semantic<br>
<br>
- while insulating bitcoin from betacoin security defects (I dont mean<br>
=A0 =A0betacoin as a testnet, it should have prudent rigorous testing like<=
br>
=A0 =A0bitcoin, just the very act of adding a feature creates risk that bit=
coin<br>
=A0 =A0stable can be hesitant to take).<br>
<br>
Probably the main issue as always is more (trustable) very high caliber<br>
testers and developers. =A0Maybe if the alt-coin minded startups and<br>
developers donate their time to bitcoin-beta (or bitcoin-stable) for the<br=
>
bits they are missing, we&#39;ll get more hands to work on something of reu=
sable<br>
value to humanity, in parallel with their startup&#39;s objectives and as a=
 way<br>
for them to get their needed features, while giving back to the bitcoin<br>
community, and helping bitcoin progress faster.<br>
<br>
Maybe bitcoin foundation could ask for BTC donations to hire more developer=
s<br>
and testers full time. =A0$1.5b of stored value should be interested to saf=
e<br>
guard their value store, and develop the transaction features.<br></blockqu=
ote><div><br></div><div>I think there may be a simpler way to do this.<br><=
br></div><div>Create a new genesis block for a staging network, but in all =
other aspects, as far as possible, keep the properties the same as bitcoin.=
<br>
<br></div><div>Do not actively be opposed to it being traded, but people ne=
ed to know that, although there is no intention to reset the chain, new and=
 potentially not fully tested, changes can be rolled into the network.=A0 A=
nyone mining staging coins should be prepared for the value to go to zero.<=
br>
<br></div><div>Perhaps also a &quot;straw poll&quot; voting system could be=
 set up for those that own staging coins could sign messages saying which p=
atches they would like to test out next.=A0 When patches are stable in the =
staging area, they could be &quot;promoted&quot; to the main net ...<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Adam<br>
<div class=3D"im"><br>
On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:<br>
&gt; =A0 This is exactly what I was planning to do with the<br>
</div>&gt; =A0 inappropriately-named &quot;Ultimate Blockchain Compression&=
quot;. =A0[...]<br>
<div class=3D"im">&gt;<br>
&gt; =A0 For it to really work, it&#39;s gotta be part of the mainnet valid=
ation<br>
&gt; =A0 rules, but no way it can be evaluated realistically without some k=
ind of<br>
&gt; =A0 &quot;staging&quot;.<br>
<br>
</div><div class=3D"im">&gt; =A0 On 5/19/2013 11:08 AM, Peter Vessenes wrot=
e:<br>
&gt;<br>
&gt; =A0 I think this is a very interesting idea. As Bitcoiners, we often s=
tuff<br>
&gt; =A0 things into the &#39;alt chain&#39; bucket in our heads; I wonder =
if this idea<br>
&gt; =A0 works better as a curing period, essentially an extended version o=
f the<br>
&gt; =A0 current 100 block wait for mined coins.<br>
<br>
</div>---------------------------------------------------------------------=
---------<br>
October Webinars: Code for Performance<br>
Free Intel webinars can help you accelerate application performance.<br>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr=
om<br>
the latest Intel processors and coprocessors. See abstracts and register &g=
t;<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60134071&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60134071&amp;iu=3D/4140/ostg.clktrk</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div>

--047d7b3a84c286c05404ebb5d728--