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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 895162247
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 22:17:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDF0C1D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 22:17:13 +0000 (UTC)
Received: by wicgb1 with SMTP id gb1so3350642wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 15:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=r2PHbINCfDc6loPtqertKONaSKtvbzvW+V6WGX34Ejk=;
b=dD81c3plLgJ1whXAUUkEYSrfRrm3V7fJqePGOF7czInB6GMNRQ/qC3lt0f7Nb4Ot5m
l3qD1bRLmwyGwcbpi14g5Yne+udt+82yHGRbUePtFWNkVNR0N/ik7FyNO3CmLrxST03p
zJZ0gtMVIsoKtLAX9FuJUQg24XkdtOMBYmpEKCPKJzVT7hLsV4EU74PcKN8mzYK2rWxw
2gFhB2Ve2nLzp4gVC+L6ClGpSUDKLxgDRiqaOf9xPS/Vbzo1xeRVdK9CwSanw8VuHcHo
GM1mGPfgbA6J/j5yfQIuDp5qm1eHZmbus6UB5Bm2YboiINsX37M/p8Vc8pB6T48PkqHS
RyMA==
MIME-Version: 1.0
X-Received: by 10.194.78.10 with SMTP id x10mr6757588wjw.108.1443651432601;
Wed, 30 Sep 2015 15:17:12 -0700 (PDT)
Received: by 10.28.158.9 with HTTP; Wed, 30 Sep 2015 15:17:12 -0700 (PDT)
In-Reply-To: <CA+w+GKS01sVXqNY6a39EjqL8NVO6k1Vq6sd0VZjeqF_tsx7OAA@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
<CADm_WcbJoH27H9ckr5sfmE0gh7YbSjKr1uLse0s3b4GTT+jEAA@mail.gmail.com>
<CA+w+GKS01sVXqNY6a39EjqL8NVO6k1Vq6sd0VZjeqF_tsx7OAA@mail.gmail.com>
Date: Wed, 30 Sep 2015 18:17:12 -0400
Message-ID: <CADm_WcZpdpnov5Tiz3_3gpUyDz=rTkKKvYexBzcFLcHKDUdxJQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=047d7bfcfd86d1dd790520fe4a73
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 22:17:14 -0000
--047d7bfcfd86d1dd790520fe4a73
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what it was designed to do; if
> the user is OK with that, they should just run an SPV wallet or use
> blockchain.info or some other mechanism that consumes way fewer resources.
>
> But if you want the software you installed to achieve its stated goal, you
> *must* upgrade. There is no way around that.
>
It is correct that security is slightly reduced for full nodes that have
not upgraded. It is not correct that the choice is binary, full node or
SPV.
Any user running a not-upgraded full node still retains protection against
many attacks outside the subset related to the feature being introduced.
The field observable end result is that we do receive new features, secured
by hashpower and user full nodes, via soft fork, without a global flag day
upgrade.
Yes, a flag day hard fork upgrade is cleaner and results in higher security
due to the entire network validating the new rules. However, the
difficulty of executing hard forks would mean fewer total features to
users, if that route were chosen instead.
--047d7bfcfd86d1dd790520fe4a73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn <span dir=3D"l=
tr"><<a href=3D"mailto:hearn@vinumeris.com" target=3D"_blank">hearn@vinu=
meris.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Field experience =
shows it successfully delivers new features to end users without a global s=
oftware upgrade.</div></div></blockquote><div><br></div></span><div>The glo=
bal upgrade is required for all full nodes in both types. If a full node do=
esn't upgrade then it no longer does what it was designed to do; if the=
user is OK with that, they should just run an SPV wallet or use <a href=3D=
"http://blockchain.info" target=3D"_blank">blockchain.info</a> or some othe=
r mechanism that consumes way fewer resources.</div><div><br></div><div>But=
if you want the software you installed to achieve its stated goal, you <i>=
must</i>=C2=A0upgrade. There is no way around that.</div></div></div></div>=
</blockquote><div><br></div><div>It is correct that security is slightly re=
duced for full nodes that have not upgraded.=C2=A0 It is not correct that t=
he choice is binary, full node or SPV.</div><div><br></div><div>Any user ru=
nning a not-upgraded full node still retains protection against many attack=
s outside the subset related to the feature being introduced.</div><div><br=
></div><div>The field observable end result is that we do receive new featu=
res, secured by hashpower and user full nodes, via soft fork, without a glo=
bal flag day upgrade.</div><div><br></div><div>Yes, a flag day hard fork up=
grade is cleaner and results in higher security due to the entire network v=
alidating the new rules.=C2=A0 However, the difficulty of executing hard fo=
rks would mean fewer total features to users, if that route were chosen ins=
tead.</div><div><br></div><div><br></div></div></div></div>
--047d7bfcfd86d1dd790520fe4a73--
|
