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
|
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 D4510104D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 12:03:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
[209.85.223.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA5C3142
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 12:03:00 +0000 (UTC)
Received: by ioii196 with SMTP id i196so7503974ioi.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Sep 2015 05:03:00 -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=3UqiK2QYvOTPCCcO6kTDXSyiBCkF9DO/ZdywQb4POOI=;
b=LFGERhIfGZwL3aglM2cKaIqg75uchOTWgH3jJfNWCUx77HNmFSWosycxvvp8HeYDqU
rWaU7eihU79fbA9wAXMAKjgUADGK6KlJrtIUObObTYbJfaVbnQLH67bUm30X2me7AU6u
hhYUVuPuc6q0MbxlnMyJfe1ZJ6Afcg1meSQ9Q=
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=3UqiK2QYvOTPCCcO6kTDXSyiBCkF9DO/ZdywQb4POOI=;
b=BOcRtSR9HP49/7uOJitzcI8VabkoGa/nX0avdD4OKMS7g0fy2JAwDI3D7EaA8yZ1wF
c9WBWt1KAxEM54a/jna8vQkkRoRVpo4CjfZVwfE9enY2ygAPQrlDzUhZF6zpOwHcpp76
1QYYhNTj0W13fwpxy032Bx5XWMfN1qTFaKTdxdQHlVhsyur0iSH4Ldd4M7zf/AbdF8Ak
dnfzb01w4CdGDQ0GPnrLhuTLFPyWyoGQc5W7PoZ5h34HAJqNKp8qPXW2mcKpBpXO29YN
iwHKMS0VaDdj8Sj6p3iIDnT0wBaUIZcVln/BTYrpCHTvZwADj3GYPti/GyKEqjahXJZx
wFdw==
X-Gm-Message-State: ALoCoQkp/gXX27XQAWeq80QQpEiyLXxn9/anV3ssFwqXiel/RZ4+FTrs8quLh9Ys0MAO0yx5hQgL
MIME-Version: 1.0
X-Received: by 10.107.165.140 with SMTP id o134mr23286790ioe.29.1443528180058;
Tue, 29 Sep 2015 05:03:00 -0700 (PDT)
Received: by 10.50.226.144 with HTTP; Tue, 29 Sep 2015 05:02:59 -0700 (PDT)
In-Reply-To: <EE96B281-464B-4B17-BAF6-25F3E30AB238@gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
<4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
<CA+w+GKSm2Np92+NA77nNMB5LqSyO0=W8dziiMtGO=Jf+7KidHQ@mail.gmail.com>
<C0E61EA6-76BE-45E0-8983-A3BC26CC64CF@gmail.com>
<CA+w+GKS74iF2FNuHtds=3R9++sx9ZP-0tcq_j5XqZw9-6uHkVQ@mail.gmail.com>
<EE96B281-464B-4B17-BAF6-25F3E30AB238@gmail.com>
Date: Tue, 29 Sep 2015 14:02:59 +0200
Message-ID: <CA+w+GKTK=ceY_-e_upVJfJ3uRdGnHwTxHwAGUpLaK4VVNZgr2A@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1141fb906567310520e19859
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: Mike Hearn via 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: Tue, 29 Sep 2015 12:03:02 -0000
--001a1141fb906567310520e19859
Content-Type: text/plain; charset=UTF-8
>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>
All clients do *not* do this. Why would they? What action would they take?
Try and simulate a hard fork in some complicated roundabout manner? Why not
just do the real thing and keep things simple?
> and make unknown noops nonstandard
>
They are already non-standard. That change was made last time I brought up
the problems with soft forks. It brought soft forks that use OP_NOPs a bit
closer to the ideal of a hard fork, but didn't go all the way. I pointed
that out above in my reply to Peter's mail.
So to answer your question, no, it wouldn't satisfy my concerns. My logic
is this:
Hard forks - simple, well understood, SPV friendly, old full nodes do not
calculate incorrect ledgers whilst telling their users (via UI, RPC) that
they are fully synced. Emphasis on simple: simple is good.
Soft forks - to get the benefits of a hard fork back requires lots of extra
code, silently makes IsStandard() effectively a part of the consensus rules
when in the past it hasn't been, SPV unfriendly. Benefits? As far as I can
tell, there are none.
If someone could elucidate *what* the benefits actually are, that would be
a good next step. So far everyone who tried to answer this question gave a
circular answer of the form "soft forks are good because they are soft
forks".
--001a1141fb906567310520e19859
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>Other than the fact that doing this as a so=
ft fork requires an extra OP_DROP, how would doing this as a hard fork make=
any difference to SPV clients? If, as others have suggested, all clients w=
arn the user on unrecognized nVersion</div></blockquote><div><br></div><div=
>All clients do <i>not</i> do this. Why would they? What action would they =
take? Try and simulate a hard fork in some complicated roundabout manner? W=
hy not just do the real thing and keep things simple?</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div> and make unknown noops nonstandard</d=
iv></blockquote><div><br></div><div>They are already non-standard. That cha=
nge was made last time I brought up the problems with soft forks. It brough=
t soft forks that use OP_NOPs a bit closer to the ideal of a hard fork, but=
didn't go all the way. I pointed that out above in my reply to Peter&#=
39;s mail.</div><div><br></div><div>So to answer your question, no, it woul=
dn't satisfy my concerns. My logic is this:</div><div><br></div><div>Ha=
rd forks - simple, well understood, SPV friendly, old full nodes do not cal=
culate incorrect ledgers whilst telling their users (via UI, RPC) that they=
are fully synced. Emphasis on simple: simple is good.</div><div><br></div>=
<div>Soft forks - to get the benefits of a hard fork back requires lots of =
extra code, silently makes IsStandard() effectively a part of the consensus=
rules when in the past it hasn't been, SPV unfriendly. Benefits? As fa=
r as I can tell, there are none.</div><div><br></div><div>If someone could =
elucidate <i>what</i>=C2=A0the benefits actually are, that would be a good =
next step. So far everyone who tried to answer this question gave a circula=
r answer of the form "soft forks are good because they are soft forks&=
quot;.</div></div></div></div>
--001a1141fb906567310520e19859--
|
