public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Date: Mon, 15 Jun 2015 02:04:44 +0200	[thread overview]
Message-ID: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com> (raw)

Mike Hearn <mike@plan99.net> wrote:
> Which is why there will soon be a fork that does it.

I understand why you would be keen to scale bitcoin, everyone here is.

But as you seem to be saying that you will do a unilateral hard-fork,
and fork the code-base simultaneously, probably a number of people
have questions, so I'll start with some:

( I noticed some of your initial thoughts are online here
https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast
https://epicenterbitcoin.com/podcast/082/ )

- Are you releasing a BIP for that proposal for review?

- If the reviewers all say NACK will you take on board their suggestions?

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs.  Can you explain your rationale
for going ahead anyway?  The risks are well understood and enormous.

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks?  Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.

- If you're going it alone as it were, are you proposing that you will
personally maintain bitcoin-XT?  Or do you have a plan to later hand
over maintenance to the bitcoin developers?

- Do you have contingency plans for what to do if the non-consensus
hard-fork goes wrong and $3B is lost as a result?


As you can probably tell I think a unilateral fork without wide-scale
consensus from the technical and business communities is a deeply
inadvisable.  While apparently some companies have expressed interest
in increased scale, I can only assume they do no yet understand the
risks.  I suggest before they would actually go ahead that they seek
independent advice.

Of the overall process, I think you can agree we should not be making
technical decisions with this level of complexity and consensus risk
with financial implications of this magnitude under duress of haste?
This seems otherwise a little like the moral hazard of the 2008
financial collapse that Satoshi put the quote in the genesis block
about.

I think its best that we progress as Jeff Garzik has done to have
engineering discussions centre around BIPs, running code for review,
simulation and careful analysis.

I understand this has been going on for a long time, and some people
are frustrated with the rate of progress, but making hasty,
contentious or unilateral actions in this space is courting disaster.

Please use your considerable skills to, along with the rest of the
community, work on this problem collaboratively.

I can sincerely assure you everyone does want to scale bitcoin and
shares your long term objective on that.

Adam



             reply	other threads:[~2015-06-15  0:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15  0:04 Adam Back [this message]
2015-06-15  9:56 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Mike Hearn
2015-06-15 18:03   ` Adam Back
2015-06-15 20:55     ` Mike Hearn
2015-06-15 21:56       ` Bryan Bishop
2015-06-15 22:17         ` Faiz Khan
2015-06-15 22:56           ` Brian Hoffman
2015-06-15 23:05             ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn .
2015-06-16  0:08             ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine
2015-06-16  0:41               ` Mark Friedenbach
2015-06-16  1:17               ` Alex Morcos
2015-06-16  4:00                 ` Aaron Voisine
2015-06-17  3:54                   ` Peter Todd
2015-06-18 15:23               ` Jorge Timón
2015-06-16 11:29           ` Mike Hearn
2015-06-16 11:20         ` Mike Hearn
2015-06-16 12:33     ` Pindar Wong
2015-06-16 13:33       ` Peter Todd
2015-06-16 13:55         ` Pindar Wong
2015-06-17  3:59           ` Peter Todd
2015-06-25  6:43             ` [bitcoin-dev] " Pindar Wong
2015-06-26 19:30               ` Peter Todd
2015-06-15 22:54   ` odinn
2015-06-16  1:20     ` Eric Lombrozo
2015-06-16  5:18   ` Venzen
2015-06-16  6:09     ` Marcel Jamin
2015-06-16  9:21       ` Benjamin
2015-06-16 11:01     ` Tier Nolan
2015-06-17  3:52 ` Troy Benjegerdes

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='CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com' \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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