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
|
Return-Path: <clem.ds@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 777561721
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:08:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com
[209.85.192.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7FE61A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 12:08:37 +0000 (UTC)
Received: by qgev79 with SMTP id v79so146757632qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 05:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=CIS/nn39HjrxDMPo5HWeajGkHGOpUUOKoLR0oYl3xeE=;
b=lZhhqNql8tqpoPin49LW6iFqCZQ3GdIxcrfYuaMUj2YhDwFdeqnWa3kzpFEcGe2mm5
SY8sjgmEAhLA7wHpFwo1yuYnw97HGC4Zl5W0NAXeLq0BvHCyHcKddzLfCYuPuk2npG0j
FBnCfcbw79jkGLuCbYN/60PEEEUuyHC2hO03zeu6SXfdMtbfTxE9lHEQz6eF9f83RdYx
av8kUSAK+SVsR0PsZ0RcsYMTu/4M41kAwE9Z8Eyxp5ByxMRaV0BlOmgwJ6nnrcMEWZqW
ZMjf8xqLfh/AMEeVNqAHZEsq2ZMll6d4iXKTMwblrC7biU8BYxmJqrw5WUGiGWljtzt8
cjYg==
X-Received: by 10.140.150.131 with SMTP id 125mr40314342qhw.88.1444046917065;
Mon, 05 Oct 2015 05:08:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com>
Date: Mon, 05 Oct 2015 12:08:27 +0000
Message-ID: <CAP63atY+yH5BinWYAyxkqER5wA9Lj6pFC0LritSDLcDuBVbXrg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>,
Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a11376a7287e85105215a5f0e
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 12:08:38 -0000
--001a11376a7287e85105215a5f0e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It will get correct results about :
- the existence every block
- the existence of every transaction
It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.
I fully agree with Mike here.
Le lun. 5 oct. 2015 =C3=A0 14:04, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
> 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 eve=
n
> stop working (the same notification mechanism you would use with hardfork=
s).
>
> 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 includ=
e
> a new script operand via hardfork)?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11376a7287e85105215a5f0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It will get correct results about :<div>- the existence ev=
ery block</div><div>- the existence of every transaction</div><div><br></di=
v><div>It will get incorrect results :</div><div>- about the <i>nature</i> =
of some transactions</div><div>- and therefore, about the balances of some =
wallets.</div><div><br></div><div>I fully agree with Mike here.</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 5 oct. 2015 =
=C3=A0=C2=A014:04, Jorge Tim=C3=B3n <<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> a =C3=
=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</blockquote></div>
--001a11376a7287e85105215a5f0e--
|
