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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
|
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 30EF818EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 11:23:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1FB5E13C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 11:23:42 +0000 (UTC)
Received: by wicge5 with SMTP id ge5so115622191wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 04:23:40 -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=RhRdyv6wHk+eIAB8ptWHutBBIFYW0h+Tn2+jeAHVPRA=;
b=Slm4JQ1EjqybfOSdLJfAi0f8+X6bxz3F6Y3vsOZw2GhlNjw/lstiXV3I6f3XQ3VuGn
tsAzrqhYNzXVKnLMxmy3X2BhtZEMwEz4naPfhhEe6spCMAYXlotr4H9UCg2HA1knLOzH
LLZNtgej+u/ehJAxI7CpyDuiZYgVqWH5yfEr/iiXSUN/GNjxVUTSha4d0+WehX7NuWhI
lwakDwEl44NHUlYLInOPh+G3DOaANkPt56qmhowomDnltrbOopCaOT3DCSU01Y7UumCs
8Lpa5J4a0+xADr8GrJ7yAsvAlgvG5XnNOuGxlebqe5zvMNGNMLkR0naRAjeE7Kb8u46T
dkNg==
MIME-Version: 1.0
X-Received: by 10.180.37.232 with SMTP id b8mr11741867wik.46.1444044220200;
Mon, 05 Oct 2015 04:23:40 -0700 (PDT)
Received: by 10.28.158.9 with HTTP; Mon, 5 Oct 2015 04:23:39 -0700 (PDT)
In-Reply-To: <CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
<CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
Date: Mon, 5 Oct 2015 07:23:39 -0400
Message-ID: <CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=e89a8f647253c8fb71052159be25
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: Mon, 05 Oct 2015 11:23:43 -0000
--e89a8f647253c8fb71052159be25
Content-Type: text/plain; charset=UTF-8
- It is true that hard forks produce a much cleaner outcome, in terms of
well defined behavior across the entire network.
- Replacing an opcode should not result in undefined behavior. The
non-upgraded behavior is defined and deterministic.
- IsStandard remains an assistant. Miners may mine non-standard
transactions.
- "Hard forks require everyone to upgrade and soft forks don't" Doesn't
require tons of explanation: Non upgraded clients continue working on the
network even after the rules are upgraded.
All those corrections aside, I do think there has been too much hysteria
surrounding hard forks. Hard forks, when done right, produce a much
cleaner system for users.
On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Putting aside stupid arguments about who is older or who starting using
> the term SPV wallet first, let me try and make a better suggestion than
> what's in the BIP. How about the following:
>
> A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
> The default is all. When set to "standardonly", non-standard scripts are
> not checked but others are. This is similar to the behaviour during a soft
> fork. In "none" you have something a bit like SPV mode, but still
> calculating the UTXO set. This flag is simple and can be implemented in a
> few lines of code. Then an unused opcode is used for CLTV, so making it a
> hard fork.
>
> This has the following advantages:
>
> - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in
> to it if they want it. This prioritises availability (in a sense) over
> correctness.
>
> - But otherwise, nodes will prioritise correctness by default, which
> is how it should be. This isn't PHP where nonsensical code the interpreter
> doesn't understand just does ...... something. This is financial software
> where money is at risk. I feel very strongly about this: undefined
> behaviour is fine *if you opted into getting it. *Otherwise it should
> be avoided whenever possible.
>
> - SPV wallets do the right thing by default.
>
> - IsStandard doesn't silently become a part of the consensus rules.
>
> - All other software gets simpler. It's not just SPV wallets. Block
> explorers, for example, can just add a single line to their opcode map.
> With a soft fork they have to implement the entire soft fork logic just to
> figure out when an opcode transitioned from OP_NOP to CLTV and make sure
> they render old scripts differently to new scripts. And they face tricky
> questions - do they render an opcode as a NOP if the miner who built it was
> un-upgraded, or do they calculate the flag day and change all of them after
> that? It's just an explosion of complexity.
>
> Many people by now have accepted that hard forks are simpler, conceptually
> cleaner, and prioritise correctness of results over availability of
> results. I think these arguments are strong.
>
> So let me try addressing the counter-arguments one more time:
>
> - Hard forks require everyone to upgrade and soft forks don't. I still
> feel this one has never actually been explained. There is no difference to
> the level of support required to trigger the change. With the suggestion
> above, if someone can't or won't upgrade their full node but can no longer
> verify the change, they can simply restart with -scriptchecks=standardonly
> and get the soft fork behaviour. Or they can upgrade and get their old
> security level back.
>
> - Hard forks are somehow bad or immoral or can lead to "schisms". This
> is just saying, if we hold a vote, the people who lose the vote might try
> starting a civil war and refuse to accept the change. That's not a reason
> to not hold votes.
>
> But at any rate, they can do that with soft forks too: just decide
> that any output that contains OP_CLTV doesn't make it into the UTXO set.
> Eventually coins that trace back to such an output will become unusable in
> the section of the economy that decided to pick a fight.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--e89a8f647253c8fb71052159be25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>- It is true that hard forks produce a much clean=
er outcome, in terms of well defined behavior across the entire network.</d=
iv><div><br></div><div>- Replacing an opcode should not result in undefined=
behavior.=C2=A0 The non-upgraded behavior is defined and deterministic.</d=
iv><div><br></div><div>- IsStandard remains an assistant.=C2=A0 Miners may =
mine non-standard transactions.</div><div><br></div><div>- "<span styl=
e=3D"font-size:13px">Hard forks require everyone to upgrade and soft forks =
don't" =C2=A0 Doesn't require tons of explanation: =C2=A0Non u=
pgraded clients continue working on the network even after the rules are up=
graded.</span></div><div><span style=3D"font-size:13px"><br></span></div><d=
iv><span style=3D"font-size:13px">All those corrections aside, I do think t=
here has been too much hysteria surrounding hard forks.=C2=A0 Hard forks, w=
hen done right, produce a much cleaner system for users.</span></div><div><=
span style=3D"font-size:13px"><br></span></div><div><span style=3D"font-siz=
e:13px"><br></span></div><div><span style=3D"font-size:13px"><br></span></d=
iv><div><span style=3D"font-size:13px"><br></span></div><div><br></div><div=
><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev=
<span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Putting asi=
de stupid arguments about who is older or who starting using the term SPV w=
allet first, let me try and make a better suggestion than what's in the=
BIP. How about the following:</div><div><br></div><div>A new flag is intro=
duced to Core, --scriptchecks=3D[all,standardonly,none]. The default is all=
. When set to "standardonly", non-standard scripts are not checke=
d but others are. This is similar to the behaviour during a soft fork. In &=
quot;none" you have something a bit like SPV mode, but still calculati=
ng the UTXO set. This flag is simple and can be implemented in a few lines =
of code. Then an unused opcode is used for CLTV, so making it a hard fork.=
=C2=A0</div><div><br></div><div>This has the following advantages:</div><di=
v><ul><li>Nodes that want the pseudo-SPV behaviour of a soft fork can opt i=
n to it if they want it. This prioritises availability (in a sense) over co=
rrectness.<br><br></li><li>But otherwise, nodes will prioritise correctness=
by default, which is how it should be. This isn't PHP where nonsensica=
l code the interpreter doesn't understand just does ...... something. T=
his is financial software where money is at risk. I feel very strongly abou=
t this: undefined behaviour is fine <i>if you opted into getting it. </i>Ot=
herwise it should be avoided whenever possible.<br><br></li><li>SPV wallets=
do the right thing by default.<br><br></li><li>IsStandard doesn't sile=
ntly become a part of the consensus rules.<br><br></li><li>All other softwa=
re gets simpler. It's not just SPV wallets. Block explorers, for exampl=
e, can just add a single line to their opcode map. With a soft fork they ha=
ve to implement the entire soft fork logic just to figure out when an opcod=
e transitioned from OP_NOP to CLTV and make sure they render old scripts di=
fferently to new scripts. And they face tricky questions - do they render a=
n opcode as a NOP if the miner who built it was un-upgraded, or do they cal=
culate the flag day and change all of them after that? It's just an exp=
losion of complexity.</li></ul><div>Many people by now have accepted that h=
ard forks are simpler, conceptually cleaner, and prioritise correctness of =
results over availability of results. I think these arguments are strong.</=
div><div><br></div><div>So let me try addressing the counter-arguments one =
more time:</div><div><ul><li>Hard forks require everyone to upgrade and sof=
t forks don't. I still feel this one has never actually been explained.=
There is no difference to the level of support required to trigger the cha=
nge. With the suggestion above, if someone can't or won't upgrade t=
heir full node but can no longer verify the change, they can simply restart=
with -scriptchecks=3Dstandardonly and get the soft fork behaviour. Or they=
can upgrade and get their old security level back.<br><br></li><li>Hard fo=
rks are somehow bad or immoral or can lead to "schisms". This is =
just saying, if we hold a vote, the people who lose the vote might try star=
ting a civil war and refuse to accept the change. That's not a reason t=
o not hold votes.<br><br>But at any rate, they can do that with soft forks =
too: just decide that any output that contains OP_CLTV doesn't make it =
into the UTXO set. Eventually coins that trace back to such an output will =
become unusable in the section of the economy that decided to pick a fight.=
<br></li></ul><div><br></div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--e89a8f647253c8fb71052159be25--
|
