MIME-Version: 1.0
In-Reply-To: <20130522033720.GE20236@zooko.com>
References: <20130519132359.GA12366@netbook.cypherspace.org>
	<CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com>
	<20130522033720.GE20236@zooko.com>
Date: Wed, 22 May 2013 00:12:52 -0400
Message-ID: <CA+8xBpduTWaEzQAyF8j4XrdZ2A9yu5pXRB9uQ3yKzRvddsTktg@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: zooko <zooko@zooko.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Precedence: list

On Tue, May 21, 2013 at 11:37 PM, zooko <zooko@zooko.com> wrote:
> Folks:
>
> I'm very interested in this idea. I got really excited about it and started
> trying to write up schemes to implement it. Like much of Bitcoin, it gets my
> head spinning, but then it turns out I don't really understand it.
>
> Because when my write-ups of implementations all turned to dust and ashes, then
> I reconsidered, and I realized that I don't actually understand how the
> proposed thing is different than testnet. The proposed difference seems to be
> about assigning real value to the coins on this "beta bitcoin blockchain", but
> that's mostly not up to developers, except possibly through some crazy scheme
> which forces "beta bitcoins" to be exchangeable for real bitcoins... Actually,
> no, not even then.

Note that testnet operates under the threat of being reset at any
time, if someone comes along and destroys its usefulness with spam or
mining or whatnot.  That guarantees it remains a testing tool, and not
a real alt-currency.  The current testnet is the third iteration,
hence you see "testnet3" in some source code.

This option is always available for any merge-mined chain as well,
ensuring little real value is assigned to the test chain.

But that is a binary decision:  If you don't have a reset-the-chain
policy, you have a de facto "it is a real currency" policy.


> So I guess what is *really* exciting about this idea has nothing to do with
> making the "beta" coins valuable nor with novel schemes for linking
> semi-independent blockchains. What is really exciting about it is a shared
> codebase that the Bitcoin core developers are (at least nominally) paying
> attention to, and that you can play with on some public blockchain.
>
> So if that's the right goal, then the solution is a branch or a fork on github,
> and a name such as "bitcoin-next" or "bitcoin-staging" or whatever that confers
> a certain aura of relevance.
>
> And maybe some publicly celebrated list of the testnet blockchain forks which
> have been inevitably created by this "bitcoin-next" codebase.
>
> It would give people with the "better Bitcoin bug" (such as me) a common
> codebase to aim pull requests at, and to fork on github.

A fork of the bitcoin.git codebase has the nice attribute of making it
easy to "upstream" any useful changes that are not specific to that
one alt-coin.


> This feels different to me from the "go do it on an alt coin" idea, because If
> suspect most bitcoin core devs aren't really paying that much attention to alt
> coin. I know *I'm* not paying attention to them, because I'm already overloaded
> with things to learn. Having to learn about alt coins in order to try to
> communicate with bitcoin core devs that may or may not be really paying
> attention to the alt coin sounds daunting.

What's neat about bitcoin is that it invented a whole new /category/
of technology.  It's not just /an/ invention, but opened up all this
new experimentation with the new concept of money itself.

However for the bitcoin.git reference implementation, it makes more
sense to focus on supporting existing bitcoin users.  That permits
alt-coins to bubble up (or not) organically, and at the same time
reduces user confusion.  We have enough trouble explaining the basics
of bitcoin to the world; trying to keep follow every alt-coin
bandwagon just muddies the waters from a messaging standpoint.

alt-coin changes fall into two categories:
1) Rule changes.  We don't want these.
2) Generic bug fixes, cleanups, changes etc.  It would be nice to see
improvements bubble up, benefitting everybody.


-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com