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
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 226FF728
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:13:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65499CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:13:42 +0000 (UTC)
Received: by mail-pg0-f53.google.com with SMTP id x23so81796330pgx.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 16:13:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=suNElvc+7d2FoKBV7icKxcGGb60tdUJfGn40WHTPrsk=;
b=jOPKSIZeJo70H7Ce9Odvu9fmrBSLKuPeefa+1fSSoK0F01bGR2UXwpnJemrTj2I6ls
OssSgiuR1O2c84NWnp5I7uPlNXsAAJMnJah8+2K8T6oiAZ3+kofvauT1x9+6nFMKId/9
wrKWHjdnfuATSpWW/u2mn0KFrKKQlXtMAS6FgohlWAP4NtVsL6t+r1ZlnHGq1UUujBnZ
lvckqdmWG3MGP7tNxOJNmhUA8Dn6w1rK2mNNTE1ylEgIZopURzEYfP5N6ToGlt6qMpRu
YdcJXAVgH+Soi3ftjEm/hh7LWoXYWLN4WSLVA7WoH6WTrW1tYIEfACW8RHiNY1bj2LQ0
Lvgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=suNElvc+7d2FoKBV7icKxcGGb60tdUJfGn40WHTPrsk=;
b=WiDDPNffCR0JoKY2+PmpdLyrBGbGEIKGYK9tO5mpGIlQPL0+Z+0DquxDkUfj3LKCb5
1yMPZOpp0WVaudryWJ0l9Jkhc76kWi3WQeVLNbhfBQF7PHVWboV4WXz1V+TqnZz7l5GT
KkuPEBOOoESFepC7U+nMBjbVRoyRkTaZIZNQ4lh/V0j9c0isU1/lvz5Tf2BId5x55CJ+
OqddSD4mqgoYKJ+IqtzgSEqiQBKtKtmJ0srLfm2rNEiGskOyGyxC81Et3T0AKR7TNkAi
7POvdkU4hacOpupmLlhefQMUArJypCeoBT1FTpD2cHJTN9VzAcd4IPG1UHlvWqNM9cpm
NJgA==
X-Gm-Message-State: ABUngvf+432PklxFkOFMYnsMvEcgEEzT4yyvura4xoM4LgUcuA84fADZqo2pmjsjFRQB0g==
X-Received: by 10.99.123.87 with SMTP id k23mr672441pgn.101.1479341621599;
Wed, 16 Nov 2016 16:13:41 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:8084:4206:2529:776d?
([2601:600:9000:d69e:8084:4206:2529:776d])
by smtp.gmail.com with ESMTPSA id
c128sm344654pfc.39.2016.11.16.16.13.40
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Nov 2016 16:13:41 -0800 (PST)
To: Thomas Kerin <me@thomaskerin.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
<e86b5b85-591d-5342-6a75-3ebd501f1789@thomaskerin.io>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <8e7c78eb-29f7-7235-422a-9adcd50b8ac9@voskuil.org>
Date: Wed, 16 Nov 2016 16:13:42 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <e86b5b85-591d-5342-6a75-3ebd501f1789@thomaskerin.io>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="q9CPKNo2GEdXLToCVcvwuS3tglNbS9Ovo"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 17 Nov 2016 00:17:00 +0000
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: Thu, 17 Nov 2016 00:13:43 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--q9CPKNo2GEdXLToCVcvwuS3tglNbS9Ovo
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 11/16/2016 06:18 AM, Thomas Kerin wrote:
> BIP30 actually was given similar treatment after a reasonable amount of=
> time had passed.
> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
BIP30 was the resolution to a catostrophic protocol flaw that would
impact any block whether above or below the point where the rule was
applied. Applying it to all future blocks, regardless of whether there
is a reorg back to genesis, was the only option as far as I can tell. So
the comparison to an unnecessary fork is hardly apt.
> You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
> neither benefited nor improved bitcoin, but did document an event for
> posterity.
BIP50 documents the release of an "unexpected" hard fork to a large
number of users. Given that Core code is considered by some to be the
*definition* of the true protocol, this led to two "legitimate" Bitcoin
chains. Leveraging the centralized state of Bitcoin mining, the
development team was able to kill the newer chain. This was simply an
altcoin that didn't survive because people stopped using it.
Anyone can create an altcoin - the question here is specifically, why
would we want to do so in this case.
> This is not a hard fork. Removing ISM just means we've committed to
> those soft-forks only locking into the chain we use now.
There didn't seem to be any confusion among the implementers that it is
a hard fork.
I will correct one implication I made below. The heights in the proposal
are required in the absence of BIP34-style activation so that the soft
fork validation rules can be properly enforced at those points (whether
or not a deep reorg happens).
e
> On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:
>> This sort of statement represents one consequence of the
>> aforementioned bad precedent.
>>
>> Are checkpoints good now? Are hard forks okay now?
>>
>> What is the maximum depth of a reorg allowed by this non-machine
>> consensus?
>>
>> Shouldn't we just define a max depth so that all cruft deeper than
>> that can just be discarded on a regular basis?
>>
>> Why are there activation heights defined by this hard fork if it's not=
>> possible to reorg back to them?
>>
>> The "BIP" is neither a Proposal (it's been decided, just documenting
>> for posterity), nor an Improvement (there is no actual benefit, just
>> some tidying up in the notoriously obtuse satoshi code base), nor
>> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has=
>> been CoreCoin).
>>
>> e
>>
>> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail.com
>> <mailto:jameson.lopp@gmail.com>> wrote:
>>
>>> 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
>>> <mailto: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
>>> <mailto: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 activat=
ing
>>> > 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 consensu=
s
>>> > 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
>>> <mailto: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
>>> <mailto: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
>>> <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 enforc=
ed.
>>> >>
>>> >> The full draft can be found here:
>>> >>
>>> >>
>>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buri=
ed-deployments.mediawiki
>>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-bur=
ied-deployments.mediawiki>
>>> >>
>>> >> _______________________________________________
>>> >> bitcoin-dev mailing list
>>> >> bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
>>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> bitcoin-dev mailing list
>>> >> bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
>>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>> >>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> <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
>=20
--q9CPKNo2GEdXLToCVcvwuS3tglNbS9Ovo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJYLPY2AAoJEDzYwH8LXOFO0CkH/i/V+TYfHPFc9RLEnyIX85bS
ACEYuhcWQ+IgPKQ0jzEn62AqWDqc/FdsmqDeEKIoIgJdU45/IjtPKtRoQQ8txryB
ZXpcvQWFcrX7RyjOg2Pk62LQbz8o1dhDcFI5J7mSRERRNdk4OVOIg4YM7bPbOfg0
QrJ1dUXKtv83HXzGKGYoFNbgnleBXLi64Zc/pkb7Wrko74w84/o91RKfVl23g1gr
ysPrp0E1jt05JXUEqdGytP3zNJWixuSU03AfKaxiIV6wFHuoNWbi0mKaIoTw7fwM
AIUJkgFl3r0vPMkDyfPIrNuF0+d+Lj/R0BLE4geAXROQ5XeFNiGXZOWFefoemkQ=
=AEJT
-----END PGP SIGNATURE-----
--q9CPKNo2GEdXLToCVcvwuS3tglNbS9Ovo--
|
