From: Jeff Garzik <jgarzik@exmulti.com>
To: zooko <zooko@zooko.com>
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Date: Wed, 22 May 2013 00:12:52 -0400 [thread overview]
Message-ID: <CA+8xBpduTWaEzQAyF8j4XrdZ2A9yu5pXRB9uQ3yKzRvddsTktg@mail.gmail.com> (raw)
In-Reply-To: <20130522033720.GE20236@zooko.com>
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
next prev parent reply other threads:[~2013-05-22 4:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 13:23 [Bitcoin-development] is there a way to do bitcoin-staging? Adam Back
2013-05-19 15:08 ` Peter Vessenes
2013-05-20 6:34 ` Alan Reiner
2013-10-14 18:08 ` Adam Back
2013-10-14 18:21 ` Jeff Garzik
2013-11-21 20:22 ` coinscoins
2013-11-21 20:35 ` Melvin Carvalho
2013-11-21 21:11 ` [Bitcoin-development] bitcoin 1.x & 0.x in parallel (Re: is there a way to do bitcoin-staging?) Adam Back
2014-03-16 22:58 ` [Bitcoin-development] 2-way pegging " Adam Back
2014-03-16 23:22 ` Jorge Timón
2014-03-17 15:55 ` Gregory Maxwell
2013-10-14 18:43 ` [Bitcoin-development] is there a way to do bitcoin-staging? Michael Gronager
2013-10-14 20:20 ` Alan Reiner
2013-05-22 3:37 ` zooko
2013-05-22 4:12 ` Jeff Garzik [this message]
2013-05-20 7:12 ` Luke-Jr
2013-06-13 13:39 ` Adam Back
2013-06-14 19:20 ` Peter Todd
2013-06-14 20:50 ` Adam Back
2013-06-14 21:10 ` Luke-Jr
2013-06-14 21:25 ` Andreas Petersson
2013-06-15 0:09 ` Dennison Bertram
2013-06-15 1:57 ` Luke-Jr
2013-06-15 8:43 ` Dennison Bertram
2013-06-15 11:18 ` Melvin Carvalho
2013-06-15 13:26 ` Dennison Bertram
2013-06-16 15:46 ` Dennison Bertram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8xBpduTWaEzQAyF8j4XrdZ2A9yu5pXRB9uQ3yKzRvddsTktg@mail.gmail.com \
--to=jgarzik@exmulti.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=zooko@zooko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox