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
|
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 3E6BC727
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 22:21:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com
[209.85.192.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3695B196
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 22:21:56 +0000 (UTC)
Received: by mail-pf0-f172.google.com with SMTP id c4so32963294pfb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 14:21:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=IXn+eq0KQ26TZGWsp5zTA1TFNnQ/azR3It8pLWePBXw=;
b=XnQn8gEfCqg6uOGhkiOxgCY41rwKXuOE6qSMpYccyA+Eq9BiZBn1v7fBLg299PUDaQ
gTUq/pnCHYz3fbwCf2kmAciQcQuYhfF86jTqekDDuDFdNcIbNOjKy9vIVzo+los9OExE
LXGb8E8wAmQaWUhOTxXiRgTCObml6OhN5qZB2S6sCzeEElJ1flKJBA3Hrvy/vqvL7opx
kXu2HCH+DiRjV4ee/aE+l+Os+P18UcvGvbEP83nYnotf8msdS7LtcEZjB2i1U/LRQXzX
YPCUBFKm/y2fum1nlPDJMMT7KOPLnPq7YO0Fvpy/3CmF9AlL2E+nXhyvoagQZRyFprpT
cC0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=IXn+eq0KQ26TZGWsp5zTA1TFNnQ/azR3It8pLWePBXw=;
b=RgWW+wrVL7jbZpPTCmX9LC+ghfx0HHMawbFu404mT06kdpa/d3I9zHnYGqeWluqz3r
ut0g0aKtq/8pXbgwIGtB5DxcCdA0vsrLuO7/17vZAlGnqdCc90/I0fzO5OPM6E1/a9AF
LTBIWd9xsRuL9wBHGleQpLbGZ1P66Wk+A0OhGRX9evlvOu5Gq3iEARH/nSwEdy2wdH5f
x7B/M9eouaxJCsn2VpPeCK9fVZ2fGjv3gCaIShFJiegpf0q/WE9Wir8KxoXv9QVoVSRO
ML7tvJzi+hzVYpCjypN7KvAmMA2ksXYWSwvlTbfMN2rHTDEXCxKBPrqJu5LZJlDvzYwH
Spww==
X-Gm-Message-State: ABUngveyecNM+omDE7R+G1sUfvLukYagerpwuk2bSRNXGDjKwsNzpH7T13/WrcrUwIMkmQ==
X-Received: by 10.99.230.83 with SMTP id p19mr7784644pgj.121.1479334915838;
Wed, 16 Nov 2016 14:21:55 -0800 (PST)
Received: from [10.55.212.10] (mobile-166-176-184-208.mycingular.net.
[166.176.184.208]) by smtp.gmail.com with ESMTPSA id
131sm56971216pfx.92.2016.11.16.14.21.55
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Nov 2016 14:21:55 -0800 (PST)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <20161116210100.GC5639@savin.petertodd.org>
Date: Wed, 16 Nov 2016 14:21:53 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DD0AEAC-ACC9-4F09-B922-8235D528BBC5@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>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
<CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
<CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
<20161116210100.GC5639@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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
X-Mailman-Approved-At: Wed, 16 Nov 2016 22:24:34 +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: Wed, 16 Nov 2016 22:21:57 -0000
I would suggest that, before discussing how best to fork the chain to meet t=
his objective, we consider the objective.
The implementers have acknowledged that this does not represent a performanc=
e improvement. Especially given that this was apparently not initially under=
stood, that alone is good reason for them to reconsider.
The remaining stated objective is reduction of code complexity. Let us be ve=
ry clear, a proposal to change the protocol must be considered independently=
of any particular implementation of the protocol. While the implementation o=
f BIP34 style activation may be hugely complex in the satoshi code, it is de=
finitely not complex as a matter of necessity.
Activation constitutes maybe a dozen lines of additional code in libbitcoin.=
The need to hit the chain (or cache) to obtain historical header info will r=
emain for proof of work, so this change doesn't even accomplish some sort of=
beneficial isolation from blockchain history.
So, at best, we are talking about various ways to introduce a consensus fork=
so that a well designed implementation can remove a tiny amount of already=
-written code and associated tests. In my opinion this is embarrassingly poo=
r reasoning. It would be much more productive to reduce satoshi code complex=
ity in ways that do not impact the protocol. There are a *huge* number of su=
ch opportunities, and in fact activation is one of them. Once that is done, w=
e can talk about forking to reduce source code complexity.
These fork suggestions actually increase *necessary* complexity for any impl=
antation that takes a rational approach to forks. By rational I mean *additi=
ve*. Deleting rules from Bitcoin code is simply bad design. Rules are never r=
emoved, they are added. A new rule to modify an old rule is simply a new rul=
e. This is new and additional code. So please don't assume in this "proposal=
" that this makes development simpler for other implementations, that is not=
a necessary conclusion.
e
> On Nov 16, 2016, at 1:01 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
>> On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wro=
te:
>> I think we are misunderstanding the effect of this change.
>> It's still "OK" for a 50k re-org to happen.
>> We're just saying that if it does, we will now have potentially introduce=
d
>> a hard fork between new client and old clients if the reorg contains
>> earlier signaling for the most recent ISM soft fork and then blocks which=
>> do not conform to that soft fork before the block height encoded activati=
on.
>>=20
>> I think the argument is this doesn't substantially add to the confusion o=
r
>> usability of the system as its likely that old software won't even handle=
>> 50k block reorgs cleanly anyway and there will clearly have to be human
>> coordination at the time of the event. In the unlikely event that the ne=
w
>> chain does cause such a hard fork, that coordination can result in everyo=
ne
>> upgrading to software that supports the new rules anyway.
>>=20
>> So no, I don't think we should add a checkpoint. I think we should all
>> just agree to a hard fork that only has a very very slim chance of any
>> practical effect.
>=20
> So, conceptually, another way to deal with this is to hardcode a blockhash=
> where we allow blocks in a chain ending with that blockhash to _not_ follo=
w
> BIP65, up until that blockhash, and any blockchain without that blockhash m=
ust
> respect BIP65 for all blocks in the chain.
>=20
> This is a softfork: we've only added rules that made otherwise valid chain=
s
> invalid, and at the same time we are still accepting large reorgs (albeit u=
nder
> stricter rules than before).
>=20
> I'd suggest we call this a exemption hash - we've exempted a particular
> blockchains from a soft-forked rule that we would otherwise enforce.
>=20
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
