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
187
188
189
190
191
192
193
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D6F5218D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:21:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149077.authsmtp.com (outmail149077.authsmtp.com
[62.13.149.77])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id F0AE1208
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 13:21:33 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SDLWdg033945;
Mon, 28 Sep 2015 14:21:32 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SDLRmZ004542
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 28 Sep 2015 14:21:30 +0100 (BST)
Date: Mon, 28 Sep 2015 09:21:27 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <20150928132127.GA4829@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: d4f8658d-65e3-11e5-b399-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAoUC1AEAgsB AmMbWlBeUlx7WmM7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRRi cmJ8D3NydwFDfHw+ ZERjWXIVCEAsfUB4
ShpJE2hTZnphaTUa TRJbfgpJcANIexZF O1F6ACIKLwdSbGoL
FQ4vNDcwO3BTJTpg CiUAMR0JCUoGBjo7 VlgoPA1xQAUuZwgY
DDgBAX0gPWM8DGgI EHUQEDp/
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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, 28 Sep 2015 13:21:34 -0000
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote:
> There is *no* consensus on using a soft fork to deploy this feature. It
> will result in the same problems as all the other soft forks - SPV wallets
> will become less reliable during the rollout period. I am against that, as
> it's entirely avoidable.
>=20
> Make it a hard fork and my objection will be dropped.
>=20
> Until then, as there is no consensus, you need to do one of two things:
>=20
> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correct=
ly
> informed
>=20
> 2) Do nothing
Hmm? You didn't quote any of my email, so I'll remind you what I did say
we had consensus about:
2) We have consensus on the semantics of the CLTV opcode
and
3) We have consensus that Bitcoin should adopt CLTV
The broad peer review and discussion that got #6124 merged is a clear
sign that we expect CLTV to be eventually adopted. __The question isn't
if CLTV should be added to the Bitcoin protocol, but rather when.__
(emphasis mine)
Both those statements of consensus are *not* about how CLTV is to be
deployed. I did discuss deployment later:
6) We have the __necessary consensus__ to deploy CLTV via IsSuperMajori=
ty()
The various "nVersion bits" proposals - which I am a co-author of - have
the primary advantage of being able to cleanly deal with the case where
a soft-fork fails to get adopted. However, we do have broad consensus,
including across all sides of the blocksize debate, that CLTV should be
adopted. __The risk of CLTV failing to get miner adoption, and thus
blocking other soft-forks, is very low.__
I probably could have worded this section a bit more clearly; when I say
"necessary consensus" I'm referring to the consensus required for a
soft-fork deployment. At minimum a simple majority of hashing power -
your approval isn't required.
For a safe soft-fork, we'd like a super majority of miners to be on
board. For a IsSuperMajority() soft-fork - as opposed to nVersion bits -
we also need the probability of the soft-fork being rejected to be very
low. To achieve that, having consensus that CLTV is a good idea is the
best situation to be in. But that's not to say that a few dissenting
voices should be seen as a blocker to progress - rather is just makes
the deployment a bit more risky, being a sign that the consensus may
change in the future, with the soft-fork being later rejected. For
example strong objections by a respected Bitcoin developer who has made
significant contributions to the consensus codebase and protocol
development would be a strong sign that a IsSuperMajority() soft-fork
might fail, and deployment via nVersion bits is probably a better
approach. Fortunately we're not in that situation.
Hard-forks are a very different situation, with significantly more need
for very broad consensus, but that's been well discussed elsewhere.
I have three questions to you:
1) Do you agree that CLTV should be added to the Bitcoin protocol?
Ignoring the question how exactly it is added, hard-fork or soft-fork.
2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
is added to Bitcoin Core?
If you refuse to do this the risk of the soft-fork is increased a bit,
although miner support for XT has remained extremely low, and the 95%
switch-over threshold has a significant margin for error. (there's a 75%
threshold to consider as well, however as XT has adopted my pull-req
#5000 - Discourage NOPs reserved for soft-fork upgrades - those miners
will only produce valid blocks under CLTV rules)
3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
detect advertised soft-forks and correctly handle them?
Notably, if you do this your objections against soft-forks will be met,
as the behavior of a SPV client with soft-fork detection during a
soft-fork will be identical to that client during a hard-fork. In
particular, the SPV client will correct reject invalid blocks, and
continue to follow only the longest valid chain. (modulo unadvertised
forks of course, an inherently unavoidable problem with the SPV security
model) Secondly, that code should also detect forks it doesn't know
about - as is done in Bitcoin Core already - and warn the user.
--=20
'peter'[:-1]@petertodd.org
00000000000000000d74f5def1087f3ec1571cb468e471e71f96063253988c78
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWCT7SXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMzI0MjBhZDI5ODdhZGM5NTRkZjg1NWY5YWUxMGNmNjA4
ZTkxMWI0MzFmNjQwZTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsiwQgAhR00ccLDjUQECJIzUkHL4PSj
HzO8D9h1MEZp/os8kGBAhSflVy+5FafPL+EoW8XswyshqHAj0uMdhFbSIkQXc3j4
HhW75YcmubxvM9AhZmlAxS5Ly73l8GrxyWLbH9FhFVKup7fppq5OrkFYANxINjft
Aq0w1bcJKbp12nuWFPGAMl9nYLwQ2A2RRU8cTJng/NM3kr8tB/duPkXaS3prFpwf
88+sNkO2uz4w94qRw4wR/lb6evfGJ06Pz4MDKg89LyE7teHVw+1ixL8xE0QuQXqO
k5tYS5YEd/aOWqHqUN5oS7H4+9JS3HxsQxsAul4D/hAR75sekTegDoMcy+goZg==
=gD1y
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
|
