1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z4p3i-0006Ze-U5
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 11:29:38 +0000
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;
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4p3h-0001KF-Lr
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jun 2015 11:29:38 +0000
Received: by wiga1 with SMTP id a1so105860283wig.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jun 2015 04:29:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.91.40 with SMTP id cb8mr41926308wib.64.1434454171687;
Tue, 16 Jun 2015 04:29:31 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Tue, 16 Jun 2015 04:29:31 -0700 (PDT)
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
X-Google-Sender-Auth: dVLkb0VU6_4ma9oPZmlbMBRfzas
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
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4p3h-0001KF-Lr
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
non-consensus hard-fork
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 11:29:39 -0000
--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>"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 unila=
teral hard-fork and being in sole maintainership control?"</div></span=
></div></blockquote><div><br></div><div>How do we plan to deal with securit=
y & 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'll manage. But I don't expect things to exist i=
n 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 bigge=
r blocks and as long as I have the time/energy/interest. If the >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'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't believe it'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--
|
