public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2015-09-01 10:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 20:06 [bitcoin-dev] Your Gmaxwell exchange Monarch
2015-08-31 20:27 ` Justus Ranvier
2015-08-31 20:48   ` Monarch
2015-08-31 21:24     ` Allen Piscitello
2015-08-31 21:42       ` Monarch
2015-08-31 21:54         ` Justus Ranvier
2015-08-31 22:53           ` Monarch
2015-08-31 23:24             ` Justus Ranvier
2015-09-01  0:02             ` Milly Bitcoin
2015-09-01  9:25           ` Jorge Timón
2015-08-31 23:32       ` Peter R
2015-08-31 23:47         ` s7r
2015-09-01  2:16           ` [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes Peter R
2015-09-01  2:25             ` Gregory Maxwell
2015-09-01  8:42             ` Adam Back
2015-09-01 10:16               ` Chris D'Costa [this message]
2015-09-01 11:20                 ` Monarch
2015-09-01 12:24             ` Wladimir
2015-09-01 22:06             ` s7r
2015-09-01 11:44           ` [bitcoin-dev] Your Gmaxwell exchange Monarch
2015-09-01 11:11         ` Monarch
2015-09-01 15:59           ` Dave Collins
2015-09-01 16:51             ` Monarch
2015-09-01 18:37               ` Eric Voskuil
2015-09-01 20:08                 ` Monarch

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='CAC0TF=mL1RpN5Gt75mYrVppe4gqUaK9VTHFR9uZq8N5FXv-nTQ@mail.gmail.com' \
    --to=chris.dcosta@meek.io \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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