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
|
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 E907F1985
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 10:59:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 37CB287
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 10:59:55 +0000 (UTC)
Received: by igcrk20 with SMTP id rk20so57696845igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 03:59:54 -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=JD8VZxWjkE5Sk0KM0fJo+0054ijc5ojOngJDgMrGbiQ=;
b=XMeEfi9F6nwbWIz2fmRCw88gptlbQEf4tNL8e9IZHdIbnHgIUbAtA3h7cDnMxFtF28
ZXzSdfqbXezzLpnwPhlyR49bPEmAS9j7iR9Cby0sCOzns9JQ14zsF5jDFuW7DD1EB833
UN1uzuiw0HA1oiYKlgv/kWBTkkVWfmj27JpLM=
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=JD8VZxWjkE5Sk0KM0fJo+0054ijc5ojOngJDgMrGbiQ=;
b=VjSN+KG+BpSUWq6XfZ4K1JttqjfwUnouzqcpN2S9laM05orQP2klokYPcszJXYlWmD
BLmN3QtIMIacW7fdQcgniWquICentJlRoTJcJ2ix9q32jHBUM6HiQqwTERqYDyIu4j+F
Pb3CkV9JQJDpxOkoZip6HCljohRpo5452x/+weRp8LbN2aX5kqmK4GICWTCUm2lN8/RT
1e8xqrtgsjVEyxuXE4Qsfu1t5UVbPHA9jVZBuwQHbsWY/QXrYEBOuoji9u/MzaQOQqhC
pXivVbo/Lt9zm1fUaS8aElFLhPTpQQF/qhojH7rUFZW71GVFvSl7RuL8Ko+h37gq/VsK
3DwA==
X-Gm-Message-State: ALoCoQlEPeGcFaKuGjoMHH6YQu33mB1NVLJNu4C3xJMRe63LW+Zl7ml0tA1oh3vKSTHgBHDnT1iU
MIME-Version: 1.0
X-Received: by 10.50.20.8 with SMTP id j8mr1521423ige.69.1444042794613; Mon,
05 Oct 2015 03:59:54 -0700 (PDT)
Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 03:59:54 -0700 (PDT)
In-Reply-To: <BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
Date: Mon, 5 Oct 2015 12:59:54 +0200
Message-ID: <CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: GC <slashdevnull@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7bd75266d0a708052159693e
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: Mon, 05 Oct 2015 10:59:56 -0000
--047d7bd75266d0a708052159693e
Content-Type: text/plain; charset=UTF-8
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.
--047d7bd75266d0a708052159693e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>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:</div><div><=
br></div><div>A new flag is introduced to Core, --scriptchecks=3D[all,stand=
ardonly,none]. The default is all. When set to "standardonly", no=
n-standard scripts are not checked but others are. This is similar to the b=
ehaviour during a soft fork. In "none" you have something a bit l=
ike SPV mode, but still calculating the UTXO set. This flag is simple and c=
an 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 th=
e following advantages:</div><div><ul><li>Nodes that want the pseudo-SPV be=
haviour of a soft fork can opt in to it if they want it. This prioritises a=
vailability (in a sense) over correctness.<br><br></li><li>But otherwise, n=
odes will prioritise correctness by default, which is how it should be. Thi=
s isn't PHP where nonsensical code the interpreter doesn't understa=
nd just does ...... something. This is financial software where money is at=
risk. I feel very strongly about this: undefined behaviour is fine <i>if y=
ou opted into getting it. </i>Otherwise it should be avoided whenever possi=
ble.<br><br></li><li>SPV wallets do the right thing by default.<br><br></li=
><li>IsStandard doesn't silently become a part of the consensus rules.<=
br><br></li><li>All other software gets simpler. It's not just SPV wall=
ets. Block explorers, for example, can just add a single line to their opco=
de 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 tri=
cky 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.</li></ul><div>Many pe=
ople by now have accepted that hard forks are simpler, conceptually cleaner=
, and prioritise correctness of results over availability of results. I thi=
nk these arguments are strong.</div><div><br></div><div>So let me try addre=
ssing the counter-arguments one more time:</div><div><ul><li>Hard forks req=
uire everyone to upgrade and soft forks don't. I still feel this one ha=
s never actually been explained. There is no difference to the level of sup=
port 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=3Dstandardonly and get =
the soft fork behaviour. Or they can upgrade and get their old security lev=
el back.<br><br></li><li>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 c=
hange. That's not a reason to not hold votes.<br><br>But at any rate, t=
hey can do that with soft forks too: just decide that any output that conta=
ins OP_CLTV doesn't make it into the UTXO set. Eventually coins that tr=
ace back to such an output will become unusable in the section of the econo=
my that decided to pick a fight.<br></li></ul><div><br></div></div></div></=
div>
--047d7bd75266d0a708052159693e--
|
