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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C247F19A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:04:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E34F19F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:04:15 +0000 (UTC)
Received: by wicgb1 with SMTP id gb1so116158365wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 05:04:13 -0700 (PDT)
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=3vL4irrot1KgeI0fwA15MDjb0I8c1FPk1fg92y2wjRc=;
b=QCKInItTIlhMrGd9PoS68afuRq2wRDUZl1Ei8q7XqnVcK/J0GDi1ZNQjHJg6f/4iS3
ydB3a/B+tOk32LB4yUAx/FUSnik1/haQ40empJ3305938x3MoFepyAnza1ELP6z36RFm
X1nIEp64wX5mFVLfzzqYm1y/lg2PlIx9+n4YdGp1DlfbYUAVE4GiVxhMMThWc0mXSTA3
VBWO5bA0ef/5ot0hP/uGXM/3ZAdpQnFC02eUkjmGRWhM2t2mgv/9kh7Tpsrha/1qvg79
7zwQk74dAfJmbFXGGHddrI3MuLP7gYVpfum6YICIt20Db9VdFsqYJ1N2THt8DUDPlW9L
UBFw==
X-Gm-Message-State: ALoCoQmBt++vPMPSXrqUKaCCUNI95dDf8vBEjzVVtCIYXcan+ta4dvXKiRBydbDvwBtqp+HKzO/i
MIME-Version: 1.0
X-Received: by 10.194.113.131 with SMTP id iy3mr16169620wjb.133.1444046653691;
Mon, 05 Oct 2015 05:04:13 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 05:04:12 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 05:04:12 -0700 (PDT)
In-Reply-To: <CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@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>
Date: Mon, 5 Oct 2015 14:04:12 +0200
Message-ID: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a1130cc42d52dfd05215a4f42
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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:04:15 -0000
--001a1130cc42d52dfd05215a4f42
Content-Type: text/plain; charset=UTF-8
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
But assuming the hashrate majority has upgraded (and we're using 95% as the
miner upgrade confirmation threshold to start activation, so that
assumption seems pretty safe), 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. A non-upgraded full node wallet waiting for several
confirmations (for example, 6 confirmations) will be just as safe as an
upgraded one. In that sense, it keeps working. On top of that, nodes (of
any kind) can use unknown block version numbers to notify the user or even
stop working (the same notification mechanism you would use with hardforks).
I agree that hardforks are necessary and we should deploy a hardfork asap
to show the world they are indeed possible (bip99 proposes a likely
uncontroversial one), but I still believe that is clear that softfork
deployment is preferrable in many cases like this one.
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)?
--001a1130cc42d52dfd05215a4f42
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
><br>
> Well, let's agree to disagree on these two things:<br>
><br>
> - I define "working" for a full node as verifying everything=
; if a node starts skipping bits then I'd say it's not really "=
;working" according to its original design goals</p>
<p dir=3D"ltr">But assuming the hashrate majority has upgraded (and we'=
re using 95% as the miner upgrade confirmation threshold to start activatio=
n, so that assumption seems pretty safe), a non-upgraded full node and an u=
pgraded full will converge on what they see: "the most-work valid chai=
n" will be the same for both. A non-upgraded full node wallet waiting =
for several confirmations (for example, 6 confirmations) will be just as sa=
fe as an upgraded one. In that sense, it keeps working. On top of that, nod=
es (of any kind) can use unknown block version numbers to notify the user o=
r even stop working (the same notification mechanism you would use with har=
dforks).</p>
<p dir=3D"ltr">I agree that hardforks are necessary and we should deploy a =
hardfork asap to show the world they are indeed possible (bip99 proposes a =
likely uncontroversial one), but I still believe that is clear that softfor=
k deployment is preferrable in many cases like this one.</p>
<p dir=3D"ltr">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)?<br>
</p>
--001a1130cc42d52dfd05215a4f42--
|
