From: Mike Hearn <mike@plan99•net>
To: Faiz Khan <faizkhan00@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Date: Tue, 16 Jun 2015 13:29:31 +0200 [thread overview]
Message-ID: <CANEZrP1c9LHcEOpBPjBhRY06vHn_6oQ4ndydS1gV109FhKLF4g@mail.gmail.com> (raw)
In-Reply-To: <CALx=ga7axVzUvpUd5Fvr=UruzUZWhXqJ7ibCEzjrRC-58gSWjw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>
How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.
Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!
That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.
So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.
Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.
Does that help clear things up?
[-- Attachment #2: Type: text/html, Size: 2631 bytes --]
next prev parent reply other threads:[~2015-06-16 11:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 0:04 Adam Back
2015-06-15 9:56 ` 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 [this message]
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=CANEZrP1c9LHcEOpBPjBhRY06vHn_6oQ4ndydS1gV109FhKLF4g@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=faizkhan00@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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