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
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
|
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B89B256
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 13:29:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
[209.85.218.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95574285
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 13:29:42 +0000 (UTC)
Received: by mail-oi0-f49.google.com with SMTP id 128so59899573oih.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 05:29:42 -0800 (PST)
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; bh=7owFq+sA4MW371X6ROKiO7a2Y58dG2wVtjpjfC+iZNk=;
b=kzjk5cVuClWnJSHFL4L4Qf6HH8JZFNEwNECRsgTOXW6byQxpUJ2Txu4bgpwg/l5sgk
sWNAsaG1TOpX2sOP5Y2anoS+EH4oCu2yqDBiIQDJK5zGwkldqEQVleqtavNDaCXhC6vb
RjdgB91GsBwEr0NgKa+Kn3mtPnPlIjhF+eUhXgaJUo4zhx88S9RO3Bu6EpWdi9so40OC
K3aPEqZHRJpDPfFl/jGvLEQaj276iGxMqEKjQJgZT0pUGM3OHQUmIQwMxWP/7+krFd3C
XoR3Jm90TJuihQN2dJRMFYqHHhfRY8X9cUFz5WY0VhqlT7jyISoVYeO6yr/b2G0/IKIq
Vpyg==
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:from:date
:message-id:subject:to:cc;
bh=7owFq+sA4MW371X6ROKiO7a2Y58dG2wVtjpjfC+iZNk=;
b=jTgfLtuiKLsI/iQKopuq21kCMmmOhviweOaGyY0ke8yRDOwpDarP+wkSObNiLrfelV
P9GjwKSBySMrKO3+BfhKdH/Y4taOJnWiATqzDsFsmlOM3xBnSg1J2P4mlb1b0v8URPLl
HrfkTQocCxAVTyhdkfcFoTuWEXdC9yih+dE3t80+Gt5g01zo7ha4WKDwPZS9/kObUjRu
poNQwbLPM1FNy2OnXrpqx9SD7p67E/uWpJJWAFPmgVairbveT33VDaEcQk3Yjtbrb+T0
GKiSch2gysnp7TREFTy0HbuV3sKPiZRR/ehaxlAArGA08b7ZoEidyETflSFgxwTq+vgt
G4mg==
X-Gm-Message-State: ABUngvfKow7ET8mMfX3jxjVq7anoX9oghFWOSKyLXNcnZUsWmKwyQcRgMEyyrXvKTKr2XRQ4Y9KfQQ81tWunzg==
X-Received: by 10.202.89.9 with SMTP id n9mr2227937oib.141.1479302981897; Wed,
16 Nov 2016 05:29:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.106.9 with HTTP; Wed, 16 Nov 2016 05:29:41 -0800 (PST)
In-Reply-To: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Wed, 16 Nov 2016 08:29:41 -0500
Message-ID: <CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113d632ec052cb05416b1022
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 16 Nov 2016 13:29:43 -0000
--001a113d632ec052cb05416b1022
Content-Type: text/plain; charset=UTF-8
Since "buried deployments" are specifically in reference to historical
consensus changes, I think the question is more one of human consensus than
machine consensus. Is there any disagreement amongst Bitcoin users that
BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66
activated at block 363725? Somehow I doubt it.
It seems to me that this change is merely cementing into place a few
attributes of the blockchain's history that are not in dispute.
- Jameson
On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Actually this does nothing to provide justification for this consensus
> rule change. It is just an attempt to deflect criticism from the fact that
> it is such a change.
>
> e
>
> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail.com> wrote:
> >
> > I think this is already covered in the BIP text:-
> >
> > "As of November 2016, the most recent of these changes (BIP 65,
> > enforced since December 2015) has nearly 50,000 blocks built on top of
> > it. The occurrence of such a reorg that would cause the activating
> > block to be disconnected would raise fundamental concerns about the
> > security assumptions of Bitcoin, a far bigger issue than any
> > non-backwards compatible change.
> >
> > So while this proposal could theoretically result in a consensus
> > split, it is extremely unlikely, and in particular any such
> > circumstances would be sufficiently damaging to the Bitcoin network to
> > dwarf any concerns about the effects of this proposed change."
> >
> >
> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> NACK
> >>
> >> Horrible precedent (hardcoding rule changes based on the assumption that
> >> large forks indicate a catastrophic failure), extremely poor process
> >> (already shipped, now the discussion), and not even a material
> performance
> >> optimization (the checks are avoidable once activated until a
> sufficiently
> >> deep reorg deactivates them).
> >>
> >> e
> >>
> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Hi,
> >>
> >> Recently Bitcoin Core merged a simplification to the consensus rules
> >> surrounding deployment of BIPs 34, 66, and 65
> >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change
> is a
> >> minor one, I thought it was worth documenting the rationale in a BIP for
> >> posterity.
> >>
> >> Here's the abstract:
> >>
> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> >> signaling in block version numbers. Now that the chain has long since
> passed
> >> the blocks at which those consensus rules have triggered, we can (as a
> >> simplification and optimization) replace the trigger mechanism by
> caching
> >> the block heights at which those consensus rules became enforced.
> >>
> >> The full draft can be found here:
> >>
> >> https://github.com/sdaftuar/bips/blob/buried-deployments/
> bip-buried-deployments.mediawiki
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113d632ec052cb05416b1022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div></div>Since "buried deployments" =
are specifically in reference to historical consensus changes, I think the =
question is more one of human consensus than machine consensus. Is there an=
y disagreement amongst Bitcoin users that BIP34 activated at block <span cl=
ass=3D"gmail-blob-code-inner"><span class=3D"gmail-pl-c1">227931,</span></s=
pan> BIP65 activated at block <span class=3D"gmail-blob-code-inner"><span c=
lass=3D"gmail-pl-c1">388381, and BIP66 activated at block </span></span><sp=
an class=3D"gmail-blob-code-inner"><span class=3D"gmail-pl-c1">363725? Some=
how I doubt it.<br><br></span></span></div><span class=3D"gmail-blob-code-i=
nner"><span class=3D"gmail-pl-c1">It seems to me that this change is merely=
cementing into place a few attributes of the blockchain's history that=
are not in dispute.<br><br></span></span></div><span class=3D"gmail-blob-c=
ode-inner"><span class=3D"gmail-pl-c1">- Jameson<br></span></span></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Nov 15, 2016=
at 5:42 PM, Eric Voskuil via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">Actually this does nothing to provide justification for this consen=
sus rule change. It is just an attempt to deflect criticism from the fact t=
hat it is such a change.<br>
<br>
e<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
> On Nov 15, 2016, at 9:45 AM, Btc Drak <<a href=3D"mailto:btcdrak@gm=
ail.com">btcdrak@gmail.com</a>> wrote:<br>
><br>
> I think this is already covered in the BIP text:-<br>
><br>
> "As of November 2016, the most recent of these changes (BIP 65,<b=
r>
> enforced since December 2015) has nearly 50,000 blocks built on top of=
<br>
> it. The occurrence of such a reorg that would cause the activating<br>
> block to be disconnected would raise fundamental concerns about the<br=
>
> security assumptions of Bitcoin, a far bigger issue than any<br>
> non-backwards compatible change.<br>
><br>
> So while this proposal could theoretically result in a consensus<br>
> split, it is extremely unlikely, and in particular any such<br>
> circumstances would be sufficiently damaging to the Bitcoin network to=
<br>
> dwarf any concerns about the effects of this proposed change."<br=
>
><br>
><br>
> On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>> NACK<br>
>><br>
>> Horrible precedent (hardcoding rule changes based on the assumptio=
n that<br>
>> large forks indicate a catastrophic failure), extremely poor proce=
ss<br>
>> (already shipped, now the discussion), and not even a material per=
formance<br>
>> optimization (the checks are avoidable once activated until a suff=
iciently<br>
>> deep reorg deactivates them).<br>
>><br>
>> e<br>
>><br>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Recently Bitcoin Core merged a simplification to the consensus rul=
es<br>
>> surrounding deployment of BIPs 34, 66, and 65<br>
>> (<a href=3D"https://github.com/bitcoin/bitcoin/pull/8391" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/8=
391</a>), and though the change is a<br>
>> minor one, I thought it was worth documenting the rationale in a B=
IP for<br>
>> posterity.<br>
>><br>
>> Here's the abstract:<br>
>><br>
>> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via m=
iner<br>
>> signaling in block version numbers. Now that the chain has long si=
nce passed<br>
>> the blocks at which those consensus rules have triggered, we can (=
as a<br>
>> simplification and optimization) replace the trigger mechanism by =
caching<br>
>> the block heights at which those consensus rules became enforced.<=
br>
>><br>
>> The full draft can be found here:<br>
>><br>
>> <a href=3D"https://github.com/sdaftuar/bips/blob/buried-deployment=
s/bip-buried-deployments.mediawiki" rel=3D"noreferrer" target=3D"_blank">ht=
tps://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<wbr>bip-buried=
-deployments.<wbr>mediawiki</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a113d632ec052cb05416b1022--
|
