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
|
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 461761B52
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:10:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com
[209.85.223.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA1BA1AB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:10:41 +0000 (UTC)
Received: by ioiz6 with SMTP id z6so182265167ioi.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 05:10:41 -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=/p0fnX8UBcfxGw/l0UZqa6egrAaVEdFnSluKVDl77gw=;
b=VyfHFrLeXFBDpt1PG2BTk1ToYrvOb4Vf+Uk48RCYPUHnHKSQUmDkSDa8BfI8OqQzyy
BudfCYq/QaN31zpvTSzz1vvSU8uPnK/oR1haaOxngrdQDrIagfMWGP+gO+3IApncH6NU
NgRNMu41ZoV6DKGQOGXYw3Ii7jpq6Ikkr4Cqw=
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=/p0fnX8UBcfxGw/l0UZqa6egrAaVEdFnSluKVDl77gw=;
b=YezG+FjuEx028Oq9w+j/Tqa957QgeU0t+b1ZRaW4DCySBxwGQ51rIDhJ4rjiywB1mk
UQtZ/KBQVPorD1+HeAlyV241xXQQC55SJZFkWvm4Y9ViVm9veem08Z/Chh7a6P+dZpsG
SudymypUKro8L+0KyeUBmpacr3Ouw6O3NdiCZr+dJq4jBevR8dCkZf3vMl1o533iSxKG
X8ofakkRBmMYYKnLvgDMuMx/0KNRL2wNwbmTF/ngLf5/p7jHr7jir1YNM4A4lf6XQZ9H
USdj/pQOKMFLFYDu8pPza7BpwWi2Zg0G2B3yL82bfOZxWd88yhUTMJBgtFC3D+iY6yC8
qtCQ==
X-Gm-Message-State: ALoCoQncpDJmbQhaI2StKlH3msyB+5Urvbh0eEJ0cIJgaVAMQXSB95CMr5YiOIWEvVV3v/fgrKno
MIME-Version: 1.0
X-Received: by 10.107.137.144 with SMTP id t16mr28689840ioi.102.1444047041138;
Mon, 05 Oct 2015 05:10:41 -0700 (PDT)
Received: by 10.50.123.166 with HTTP; Mon, 5 Oct 2015 05:10:40 -0700 (PDT)
In-Reply-To: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@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>
<CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
<CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
<CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
Date: Mon, 5 Oct 2015 14:10:40 +0200
Message-ID: <CA+w+GKS-AZGBSwuN1dgEs6wa-R=jHE0fmfmQ0TL9Cw9b6L71UQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113fb1e4ed2cac05215a6670
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 12:10:42 -0000
--001a113fb1e4ed2cac05215a6670
Content-Type: text/plain; charset=UTF-8
Hi Jorge,
I'm glad we seem to be reaching agreement that hard forks aren't so bad
really and can even have advantages. It seems the remaining area of
disagreement is this rollout specifically.
> a non-upgraded full node and an upgraded full will converge on what they
> see: "the most-work valid chain" will be the same for both.
>
Indeed it will, but the point of fully verifying is to *not* converge with
the miner majority, if something goes wrong and they aren't following the
same rules as you. Defining "work" as "converge with miner majority" is
fine for SPV wallets and a correct or at least reasonable definition. But
not for fully verifying nodes, where non-convergence is an explicit design
goal! That's the only thing that stops miners awarding themselves infinite
free money!
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
>
No, I'm focused on the block size issue right now. I don't think there's
much point in improving the block chain protocol if most users are going to
be unable to use it. But the modification is simple, right? You just
replace this bit:
CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode
with this
CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)
and that's it. The section *upgrade and testing plan* only says TBD so that
part doesn't even need to change at all, as it's not written yet.
--001a113fb1e4ed2cac05215a6670
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 Jorge,</div><div><br></div><div>I'm glad we seem to be reaching agr=
eement that hard forks aren't so bad really and can even have advantage=
s. It seems the remaining area of disagreement is this rollout specifically=
.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><p dir=3D"ltr">a non-upgraded full node and an upgr=
aded full will converge on what they see: "the most-work valid chain&q=
uot; will be the same for both.</p></blockquote><div>Indeed it will, but th=
e point of fully verifying is to <b>not</b>=C2=A0converge with the miner ma=
jority, if something goes wrong and they aren't following the same rule=
s as you. Defining "work" as "converge with miner majority&q=
uot; is fine for SPV wallets and a correct or at least reasonable definitio=
n. But not for fully verifying nodes, where non-convergence is an explicit =
design goal! That's the only thing that stops miners awarding themselve=
s infinite free money!</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><p dir=3D"ltr">Are you going t=
o produce a bip65 hardfork alternative to try to convince people of its adv=
antages over bip65 (it is not clear to me how you include a new script oper=
and via hardfork)?<br></p>
</blockquote></div>No, I'm focused on the block size issue right now. I=
don't think there's much point in improving the block chain protoc=
ol if most users are going to be unable to use it. But the modification is =
simple, right? You just replace this bit:</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra">=C2=A0=C2=A0<span style=3D"color:rgb(51=
,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',A=
rial,freesans,sans-serif;font-size:16px;line-height:20.48px">CHECKLOCKTIMEV=
ERIFY redefines the existing NOP2 opcode</span></div><div class=3D"gmail_ex=
tra"><span style=3D"color:rgb(51,51,51);font-family:'Helvetica Neue'=
;,Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;lin=
e-height:20.48px"><br></span></div>with this<div class=3D"gmail_extra"><spa=
n style=3D"color:rgb(51,51,51);font-family:'Helvetica Neue',Helveti=
ca,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;line-height:=
20.48px"><br></span></div><div class=3D"gmail_extra"><span style=3D"color:r=
gb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI&#=
39;,Arial,freesans,sans-serif;font-size:16px;line-height:20.48px">=C2=A0=C2=
=A0</span><span style=3D"color:rgb(51,51,51);font-family:'Helvetica Neu=
e',Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16p=
x;line-height:20.48px">CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)</spa=
n></div><div class=3D"gmail_extra"><span style=3D"color:rgb(51,51,51);font-=
family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans=
,sans-serif;font-size:16px;line-height:20.48px"><br></span></div>and that&#=
39;s it. The section <i>upgrade and testing plan</i> only says TBD so that =
part doesn't even need to change at all, as it's not written yet.</=
div>
--001a113fb1e4ed2cac05215a6670--
|
