Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.182 as permitted sender)
	client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f182.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CALx=ga7axVzUvpUd5Fvr=UruzUZWhXqJ7ibCEzjrRC-58gSWjw@mail.gmail.com>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
	<CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
	<CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q@mail.gmail.com>
	<CANEZrP148U0V7bU-u0tOTk2xWwq5wy-yU-jk805DcU_3cBHtnw@mail.gmail.com>
	<CABaSBawXZDcyR96g4hBNAiFRDpTcUJX+bMXyqGeuY5wVm4k1KQ@mail.gmail.com>
	<CALx=ga7axVzUvpUd5Fvr=UruzUZWhXqJ7ibCEzjrRC-58gSWjw@mail.gmail.com>
Date: Tue, 16 Jun 2015 13:29:31 +0200
Message-ID: <CANEZrP1c9LHcEOpBPjBhRY06vHn_6oQ4ndydS1gV109FhKLF4g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Faiz Khan <faizkhan00@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043c7e7859a2e20518a0e324
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
 non-consensus hard-fork
Precedence: list

--f46d043c7e7859a2e20518a0e324
Content-Type: text/plain; charset=UTF-8

>
> "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?

--f46d043c7e7859a2e20518a0e324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div>&quot;How=
 do you plan to deal with security &amp; incident response for the duration=
 you describe where you will have control while you are deploying the unila=
teral hard-fork and being in sole maintainership control?&quot;</div></span=
></div></blockquote><div><br></div><div>How do we plan to deal with securit=
y &amp; incident response - exactly the same way as before. Remember that X=
T is basically Core plus a few patches.=C2=A0</div><div><br></div><div>Gavi=
n and myself are both on the bitcoin-security mailing list and have been fo=
r 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!=C2=
=A0</div><div><br></div><div>That one required co-ordinated crash rollouts =
of multiple wallets across the Bitcoin ecosystem because there was a parall=
el 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 wa=
s broken =C2=A0 (I knew because at the time I had access to the Google inte=
rnal Android bug tracker). I organised the whole thing.</div><div><br></div=
><div>So I think we&#39;ll manage. But I don&#39;t expect things to exist i=
n a state of disjointness for very long. XT will rebase on top of Core and =
follow it&#39;s releases for as long as there seems to be interest in bigge=
r blocks and as long as I have the time/energy/interest. If the &gt;1mb cha=
in wins then Core will have to adopt the new ruleset or simply stop being r=
elevant, as it will have no users. That wouldn&#39;t make much sense.</div>=
<div><br></div><div>Now, there have been concerns raised that a hard fork i=
s unbelievably risky, the sky will fall, the value of Bitcoin will drop to =
zero, etc. I don&#39;t believe it&#39;s anywhere near that risky. The patch=
 Gavin is working on requires both a miner majority <i>and</i>=C2=A0also ha=
s 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 be=
en known for a long time beforehand that there was sufficiently strong cons=
ensus, there will have been messages printed to the node logs, announcement=
s in various places and so on.</div><div><br></div><div>Does that help clea=
r things up?</div></div></div></div>

--f46d043c7e7859a2e20518a0e324--