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
|
Return-Path: <sdaftuar@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C86EC2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Nov 2016 14:42:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com
[209.85.220.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E70E370
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Nov 2016 14:42:52 +0000 (UTC)
Received: by mail-qk0-f178.google.com with SMTP id x190so137228247qkb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Nov 2016 06:42:52 -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=vqGxtEQezwE/ECbQfyg4bh0S88H93yqG+Fb6TDRv31I=;
b=0edg7UWfcRIeBRE2wlyLYz8jNktj9BBFXt6IDKTXTlmaE4oDxO4cZ9ze1muXC+lvhI
rwO/uqUdmUHZYkM7WHh2UuMfBcm4dcC8XP3M+Us/Tw2VDYez6MBTeAJ18WvNd2dab685
bhhqegpXHolZVxqtBDD7htucMSSOaVTvuPIysId3JRdMM+nS52mYMHMIcT/bHXN89lDH
sartUKztLEBeAtJfcszJXcyoSuFIN/hWn9XFy5zFWy1hjpF1UkZLM0cbyZdFPgCE4ews
02PLB01nbB+E3h5b1TQ3y+7w598+XxHDbIFtfvMzJ8e5u7C6MkLXK3c0CCqMOTKAMQ0n
Dvig==
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=vqGxtEQezwE/ECbQfyg4bh0S88H93yqG+Fb6TDRv31I=;
b=gyoyXrLy9xsFfA1Lh3UoaF0TSxs89FeFE+apxFjGhO1KIQRAipB6Hv0NPyov5AdY8j
/Rc4E8sO5M5D0qu9K+M5JXj+uFyg6zyPZLZzFWO2zGnehNCzmkZE5YDxVAgLwsy5BPSu
91R2r/m8TMWTKalSWawBW9MSOTH9rjKp2ZXXe+lgS6muT2/jQJuxrE++tFDsdQR04TRG
7ypTDiDb91+jqBwyxADciRogLiNML8aRQyIpuqrkwIME6YvkTkfK4fnVYfPyhGe6OmkM
4m6SxHHN9y7DIFvZpusJDJODJ0E8cT0GVY37IA4fXvceUvx5BmL9qSm9UkbI/oWW1+sF
ZMcA==
X-Gm-Message-State: ABUngveq3mIqp2ZXkqiWzP6SiFj9v58gi0RJXNvFiXWSPSvity1ko6Uk4uXN5xlfkS/9a8Kk9UhHLSZwlujZJg==
X-Received: by 10.55.5.134 with SMTP id 128mr24972466qkf.261.1479220971317;
Tue, 15 Nov 2016 06:42:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.88.133 with HTTP; Tue, 15 Nov 2016 06:42:50 -0800 (PST)
In-Reply-To: <CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 15 Nov 2016 09:42:50 -0500
Message-ID: <CAFp6fsEqqttOKq1oyUEuwnxVxxk=u3ZejhNMX51SpL0mWGyWNQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a114c819e8a30db054157f86b
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Tue, 15 Nov 2016 14:42:53 -0000
--001a114c819e8a30db054157f86b
Content-Type: text/plain; charset=UTF-8
Just want to clarify two points:
This change has not yet appeared in any released software (but I assume it
will be in the next release, 0.14.0).
I agree that the performance optimization is not the point of this change;
I can modify the BIP draft to de-emphasize that further (perhaps remove
mention of it entirely).
On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <eric@voskuil.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
>
>
--001a114c819e8a30db054157f86b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Just want to clarify two points:</div><div><br></div>=
<div>This change has not yet appeared in any released software (but I assum=
e it will be in the next release, 0.14.0).<br></div><div><br></div><div>I a=
gree that the performance optimization is not the point of this change; I c=
an modify the BIP draft to de-emphasize that further (perhaps remove mentio=
n of it entirely).</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <span dir=3D"ltr=
"><<a href=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"=
><div></div><div>NACK</div><div><br></div><div>Horrible precedent (hardcodi=
ng rule changes based on the assumption that large forks indicate a catastr=
ophic failure), extremely poor process (already shipped, now the discussion=
), and not even a material performance optimization (the checks are avoidab=
le once activated until a sufficiently deep reorg deactivates them).</div><=
div><br></div><div>e</div><div><div class=3D"h5"><div><br>On Nov 14, 2016, =
at 10:17 AM, Suhas Daftuar via bitcoin-dev <<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linux=
foundation.org</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><=
div dir=3D"ltr">Hi,<div><br></div><div>Recently Bitcoin Core merged a simpl=
ification to the consensus rules surrounding deployment of BIPs 34, 66, and=
65 (<a href=3D"https://github.com/bitcoin/bitcoin/pull/8391" target=3D"_bl=
ank">https://github.com/bitcoin/<wbr>bitcoin/pull/8391</a>), and though the=
change is a minor one, I thought it was worth documenting the rationale in=
a BIP for posterity.</div><div><br></div><div>Here's the abstract:</di=
v><div><br></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;p=
adding:0px"><div><div>Prior soft forks (BIP 34, BIP 65, and BIP 66) were ac=
tivated via miner signaling in block version numbers. Now that the chain ha=
s long since passed the blocks at which those consensus rules have triggere=
d, we can (as a simplification and optimization) replace the trigger mechan=
ism by caching the block heights at which those consensus rules became enfo=
rced.</div></div><div><br></div></blockquote><div>The full draft can be fou=
nd here:=C2=A0</div><div><br></div><div><a href=3D"https://github.com/sdaft=
uar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki" target=
=3D"_blank">https://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<=
wbr>bip-buried-deployments.<wbr>mediawiki</a></div></div>
</div></blockquote></div></div><blockquote type=3D"cite"><div><span>_______=
_______________________<wbr>_________________</span><br><span>bitcoin-dev m=
ailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><=
/span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/ma=
ilman/listinfo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></bl=
ockquote></div><br></div>
--001a114c819e8a30db054157f86b--
|
