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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C19017C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:06:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47C0E20A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:06:01 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so102746524wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 07:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=+7GccvT3Bbx3ES4hfE8KKlQzZtTTLAeZOZd2uacdC2w=;
b=nZEZ9OxCWFwAwoq1ntF2e2IBEML9F2LkiPS8UB/0PvGry21zVborG3Dj2yjfdZTuJG
RI3pU8l3t5aPUhyA+pfS6WiShVtC+MhKF8h4cH7C917mgJnA8Vzg+mITL1J5P2Guu2J0
l/X7Z2v9xckqQCsfQUfHFHscTXpuA8Ul3QkqL1FOoSzI3QWlyuje41S4Vjv0q5Ckaf/W
csDlTWjWtNtcuT3bQucMl/w5yXAg8X6vc4N23szl0TV5Bc20C3heDONhqzfSx/OTRGF4
xfuSoehrYiqOJv7yCHSZKqjqmF6LU8hES7Sgy1l0Vz4y0jLkptiRzurXKhJS0kg3DIiy
rqZQ==
X-Received: by 10.194.174.227 with SMTP id bv3mr24596367wjc.142.1443449159935;
Mon, 28 Sep 2015 07:05:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.21.200 with HTTP; Mon, 28 Sep 2015 07:05:40 -0700 (PDT)
In-Reply-To: <CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 28 Sep 2015 15:05:40 +0100
Message-ID: <CADJgMzvCMPCto7fra+H=U3b9hCY7rCPDOV2DgOS4bLzz+PTLUg@mail.gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=089e013d0f9a6ded400520cf3296
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no 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, 28 Sep 2015 14:06:02 -0000
--089e013d0f9a6ded400520cf3296
Content-Type: text/plain; charset=UTF-8
On Mon, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is no consensus. Now pick. Lose the requirement that everyone agree
> for consensus changes, and tell people you've done it. Change the spec. Or
> do nothing.
>
Of course there is good technical consensus for CLTV by IsSuperMajority()
in the same way as BIP66 was rolled out. I believe the only open question
is whether we have to account for XT's use of versionbits (because the
standard has not been finalised). One can take the view that it is a non
issue given the almost negligible number of BIP101 blocks, but it certainly
goes away if XT also merges BIP65/CLTV.
As for risks, I think we learned a lot from BIP66:
1. miners are now aware of the risks of SPV mining near activation and are
financially incentivised not to during that period.
2. As for SPV wallets need to handle awareness of the new blocks. BitcoinJ
can play a pivotal role: as far as I am aware if we'd thought about adding
handling to BitcoinJ before activation rather than after activation[1][2],
the SPV issues would have been mitigated for the vast majority who rely on
the library. To me, this particular issue highlights our collective failure
to communicate the necessity for additional SPV handling requirements and
other preparation the ecosystem should engage in during a soft fork. This
is something we should definitely add to the release notes for the next
soft fork and advertise widely. Certainly it MUST be well documented in the
BIP65 deployment section, which it is currently not.
Lastly your objections came across very strongly (at least to my
understanding) so I am curious: Peter stated Gavin is OK with adding CLTV
support to XT, and assuming that is the case, will you object to merging it
or similarly object to adding the necessary block handling to BitcoinJ?
[1]
https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c368961a25dfd772751d1ca2a1b5b
[2]
https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa8263daa641fe118
--089e013d0f9a6ded400520cf3296
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">On M=
on, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <span dir=3D"ltr">=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>There is no consensus. Now pick. Lose the requirement that everyone a=
gree for consensus changes, and tell people you've done it. Change the =
spec. Or do nothing.</div></div></div></div></blockquote><div><br></div><di=
v>Of course there is good technical consensus for CLTV by IsSuperMajority()=
in the same way as BIP66 was rolled out. I believe the only open question =
is whether we have to account for XT's use of versionbits (because the =
standard has not been finalised). One can take the view that it is a non is=
sue given the almost negligible number of BIP101 blocks, but it certainly g=
oes away if XT also merges BIP65/CLTV.</div><div><br></div><div>As for risk=
s, I think we learned a lot from BIP66:</div><div><br></div><div>1. miners =
are now aware of the risks of SPV mining near activation and are financiall=
y incentivised not to during that period.=C2=A0</div><div>2. As for SPV wal=
lets need to handle awareness of the new blocks. BitcoinJ can play a pivota=
l role: as far as I am aware if we'd thought about adding handling to B=
itcoinJ before activation rather than after activation[1][2], the SPV issue=
s would have been mitigated for the vast majority who rely on the library. =
To me, this particular issue highlights our collective failure to communica=
te the necessity for additional SPV handling requirements and other prepara=
tion the ecosystem should engage in during a soft fork. This is something w=
e should definitely add to the release notes for the next soft fork and adv=
ertise widely. Certainly it MUST be well documented in the BIP65 deployment=
section, which it is currently not.</div><div><br></div><div>Lastly your o=
bjections came across very strongly (at least to my understanding) so I am =
curious: Peter stated Gavin is OK with adding CLTV support to XT, and assum=
ing that is the case, will you object to merging it or similarly object to =
adding the necessary block handling to BitcoinJ?</div><div><br></div><div>[=
1]=C2=A0<a href=3D"https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c=
368961a25dfd772751d1ca2a1b5b">https://github.com/bitcoinj/bitcoinj/commit/6=
f03669fbd6c368961a25dfd772751d1ca2a1b5b</a><br></div><div>[2]=C2=A0<a href=
=3D"https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa82=
63daa641fe118">https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11c=
ef2dc0caa8263daa641fe118</a></div><div><br></div></div></div></div>
--089e013d0f9a6ded400520cf3296--
|
