Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

From: "Chris D'Costa" <chris.dcosta@meek•io>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes
Date: Tue, 1 Sep 2015 12:16:04 +0200	[thread overview]
Message-ID: <CAC0TF=mL1RpN5Gt75mYrVppe4gqUaK9VTHFR9uZq8N5FXv-nTQ@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTFKDmQnFZimJPttyDdyOHbc_ffs-vV7XDwwJLLu=UPVfA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]

I think the "Kill King Bitcoin - Long Live the King" call is somewhat
inevitable, and we should expect this to happen from time-to-time, now that
the cat is out of the bag.

However, I fully agree with Adam that livenet is probably not the place to
play this game, and I'm also not convinced that testnet is either.

I often wondered if there is any appetite for a no-holds-barred, anything
goes, bitcoin fork that would allow for the kind of valuable
experimentation that Peter R is suggesting? This is a different concept
than an alt-coin because it would be undoubtedly unstable until consensus
is reached - and that is the whole idea. It hopefully would inform future
decisions about what gets rolled into Core. One problem I see with doing
this, is the lack of incentive.

Chris

On 1 September 2015 at 10:42, Adam Back via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Peter this seems to be a not well thought through course of action,
> fun though it maybe informally or philosophically or to tweak various
> peoples sensibilities.
>
> Bitcoin is a consensus system that does not work if there are
> incompatible versions of consensus code competing on the network.
> This is why work is underway on libconsensus so we can see diversity
> of implementation without the risk of incompatibility arising by
> software defect.  It has proven quite hard to match independent
> consensus implementations bit for bit against an adaptive adversary
> looking for inconsistencies in interpretation.
>
> In terms of protocol updates it is more constructive therefore that
> people with a technical interest analyse and validate others proposals
> via testing, or make their own proposals so that we can arrive at a
> well validated upgrade mechanism that everyone upgrades to in a
> coordinated fashion.
>
> Previous intentional upgrades to bitcoin have been
> backwards-compatible (via soft-fork which can be secured reasonably
> using a miner vote trigger and temporary SPV security for those who
> not yet upgraded) but the current topic of a throughput increase is
> non-backwards-compatible (via a hard-fork), and the way to minimise
> risk of such an upgrade is for everyone to try to upgrade well in
> advance of an agreed upgrade schedule, and to be all upgrading to the
> *same* consensus rule change.
>
> Encouraging nodes or miners to "vote" by running a range of different
> consensus rules isnt really constructive I feel - it alarms people who
> understand the risks, sets things on a path that have to be fixed
> while in flight by obvious implication, and isnt collaborative - so it
> risks being a politicising suggestion on what should be a purely
> technical topic of choosing the best approach, where it is best to
> strive to keep things non-emotive and professional and technically
> focussed.  Such calls are offending the technical sensibilities of
> people who understand the risks.
>
> Anyway lets try to keep things constructive and focus on analysing
> proposals.
>
> Adam
>
> On 31 August 2015 at 19:16, Peter R via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I agree, s7r, that Bitcoin Core represents the most stable code base.  To
> > create multiple implementations, other groups would fork Bitcoin Core
> > similar to what Bitcoin XT did.  We could have:
> >
> > - Bitcoin-A (XT)
> > - Bitcoin-B (Blockstream)
> > - Bitcoin-C (promoting BIP100)
> > - Bitcoin-D
> > - etc.
> >
> > Innovation from any development group would be freely integrated by any
> > other development group, if desired.  Of course, each group would have a
> > very strong incentive to remain fork-wise compatible with the other
> > implementations.
> >
> > In fact, this just gave me a great idea!  Since Wladimir has stated that
> he
> > will not integrate a forking change into Core without Core Dev
> consensus, I
> > suggest we work together to never reach consensus with Bitcoin Core.
> This
> > will provide impetus for new implementations to fork from Core (like XT
> did)
> > and implement whatever scaling solution they deem best.  The users will
> then
> > select the winning solution simply based on the code they choose to run.
> > The other implementations will then rush to make compatible changes in
> order
> > to keep their dwindling user bases.
> >
> > This is the decentralized spirit of Bitcoin in action.  Creative
> > destruction.  Consensus formed simply by the code that gets run.
> >
> > Let's kill Bitcoin Core and allow the green shoots of a garden of new
> > implementations to grow from its fertile ashes.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5965 bytes --]