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
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B5621EE6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 17:11:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC1B68C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 17:11:56 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so107404825igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 10:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=P1XFD95Xxchs7mYy6dQg0NwFlGjrT/U+SToO5UwK3gE=;
b=VmzUyd/SObm3qbwwdc1Mkxge56dErgfxyHMsCrxt7qDJJC5DiGzqnyYX+SknUDll2a
z7IfjRRJ6ocuxBcb/sHZQdTU6gBpvIerguU9gBDmFHi4HGcBPs6s1ChinlBAZFfqFPtO
b7uZQRa1Hqsh8Ka3Th+Cl24o9+Rc8CIve5sBI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=P1XFD95Xxchs7mYy6dQg0NwFlGjrT/U+SToO5UwK3gE=;
b=mqgby3Bx9mJws2c/BEgxvH00Mx5MwUjIuze13/9J5gV9RJtuyMIUk6QSANMTcgv7FY
n7GU9mN10JOzJJjdOIsAeCgKsOfeYVQTfCeBAf8H3gc4jDJtw8Lv9N+3i1IJlSzuGzXt
fZKthvO8dEv/7TT8/kNzHC4cr0HP741G7duUbUVK4F7jx4fNJshi6+9lY2NYj9G4ZdBo
e12enpLKc4/eTV40tBeIiV2h5eSBinktfDIScu6Lcq09B6aGW2Q7/vDslXTjas1FWhlM
91PIr6oAt++chbij5QDB08+s/Z38mjjmKW4e/QWSPF9mw0KsLwYVD4ag8vzXcdPPAxA/
ezKg==
X-Gm-Message-State: ALoCoQlr8aNdcOVMfd0nGIbjfl/J18sRFw99Prcc4skT6Gtuv3KO79IhmD+ByNtqVqPnyHWny6OD
MIME-Version: 1.0
X-Received: by 10.50.79.232 with SMTP id m8mr6207160igx.83.1443633116318; Wed,
30 Sep 2015 10:11:56 -0700 (PDT)
Received: by 10.50.123.166 with HTTP; Wed, 30 Sep 2015 10:11:56 -0700 (PDT)
In-Reply-To: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
Date: Wed, 30 Sep 2015 19:11:56 +0200
Message-ID: <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013a060615b16d0520fa0703
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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 17:11:57 -0000
--089e013a060615b16d0520fa0703
Content-Type: text/plain; charset=UTF-8
Hi Gregory,
> I'm surprised to see this response
Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nice philosophically because they reduce the
security model of former full nodes to SPV without their knowledge" (he
thought they were worth it anyway).
This is not a new debate. If you're surprised, it means only you weren't
paying attention to all the previous times people raised this issue.
> Have I missed a proposal to change BIP101 to be a real hardfork
There's no such thing as a "real" hard fork - don't try and move the goal
posts. SPV clients do not need any changes to do the right thing with BIP
101, they will follow the new chain automatically, so it needs no changes.
Several people have asked several times now: given the very real and widely
acknowledged downsides that come with a soft fork, *what* is the specific
benefit to end users of doing them?
Until that question is answered to my satisfaction I continue to object to
this BIP on the grounds that the deployment creates financial risk
unnecessarily. To repeat: *CLTV does not have consensus at the moment*.
BTW, in the April 2014 thread Pieter's argument was that hard forks are
more risky, which is at least an answer to my question. But he didn't
explain why he thought that. I disagree: the risk level seems lower with a
hard fork because it doesn't lower anyone's security level.
--089e013a060615b16d0520fa0703
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"><div=
>Hi Gregory,</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm =
surprised to see this response</blockquote><div><br></div><div>Why? I have =
objected to the idea of soft forks many times. I wrote an entire article ab=
out it in August. I also objected in April 2014, for instance, where Pieter=
agreed with me that soft forks can result in ugly hacks, and that they are=
"not nice philosophically because they reduce the security model of f=
ormer full nodes to SPV without their knowledge" (he thought they were=
worth it anyway).</div><div><br></div><div>This is not a new debate. If yo=
u're surprised, it means only you weren't paying attention to all t=
he previous times people raised this issue.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Have I missed a proposal to change BIP101 to be a rea=
l hardfork</blockquote><div><br></div><div>There's no such thing as a &=
quot;real" hard fork - don't try and move the goal posts. SPV clie=
nts do not need any changes to do the right thing with BIP 101, they will f=
ollow the new chain automatically, so it needs no changes.</div><div><br></=
div><div>Several people have asked several times now: given the very real a=
nd widely acknowledged downsides that come with a soft fork, <b>what</b>=C2=
=A0is the specific benefit to end users of doing them?=C2=A0</div><div><br>=
</div><div>Until that question is answered to my satisfaction I continue to=
object to this BIP on the grounds that the deployment creates financial ri=
sk unnecessarily. To repeat:=C2=A0<b>CLTV does not have consensus at the mo=
ment</b>.</div><div><br></div><div>BTW, in the April 2014 thread Pieter'=
;s argument was that hard forks are more risky, which is at least an answer=
to my question. But he didn't explain why he thought that. I disagree:=
the risk level seems lower with a hard fork because it doesn't lower a=
nyone's security level.<br></div></div></div></div>
--089e013a060615b16d0520fa0703--
|
