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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 433F4B1F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 02:47:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
[209.85.217.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6598F22C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 02:47:35 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id b35so131231199uaa.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 18:47:35 -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=Ewk/m/Ee9IXki+z+0W+hl2YpjXEqJgkUnvXz57yqaBw=;
b=H+Yu/GRtTjewGNApVPskNX15Uo3+I/Tjpkjtg8HmZgxCHpVnXQ5K1X+UBZXFeSYhtD
jI24lQVpyoosnSqjLQcfY/RJJGKPwSH8GElsh1TmYewRoN9DSWBic3a38X5qwwXK62t3
RVGjp27SspqT3+fu8EGELLaQWheUoT6dFU+sfke7g7y45wzAKnkOgSbyt8Q8N+y3Vxmi
+b83XwTs2ofC37lMlZF3DtY4DtfEhzVrTcgvi25Og2xl5UYYJeU/zudpJid3CW8KssUK
u4wmzH6EnmpNdcbyTU3oKdHRgEB4YrZsfsoKMtzknubCnvFWBjEER5nyO+Z8YIM8j8Sg
icbw==
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=Ewk/m/Ee9IXki+z+0W+hl2YpjXEqJgkUnvXz57yqaBw=;
b=epe0Swweb8i8D2E7UZBaDZxyZy9k2uvbuf4qXr5mIiW+gb0OBJn2v+ROZuj+kL88Qf
RhzAvTge3C1eMvy+dArrck9N83ORDb8PmTnPbnmk0ti4D76+LteAoSuvC2sTeUFFvzQl
g8VF0tVjWm456ilQFR0RwzM6LdJMb+uiu80WdXjXsmszeGoC6682GD/cpycvYpbjTrmk
mGISCzK3mJYrxWHN22uyqePySd2dT+CrOeZ/h3Yre0WnKRpR66Jb6AKRDQMe23XFHWwJ
6tFtmu6PYLZo/BHOsospg4mAh3K419FBlhC95c2QCY3olPDAGYy+UM4Hm2YtC4UwCr0J
mTqg==
X-Gm-Message-State: ABUngveCQ54QZaKMp9O1apa0ajF+2k/Tcz3WMdQV8K3UzCxkG+9BMVlFAbwzmdfc6cZ4xerbJyXN2ivpVpMsOA==
X-Received: by 10.176.65.33 with SMTP id j30mr430036uad.94.1479350854561; Wed,
16 Nov 2016 18:47:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.115.201 with HTTP; Wed, 16 Nov 2016 18:47:33 -0800 (PST)
In-Reply-To: <0d66bf24-2ded-cd98-ec55-945e01b436d0@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>
<CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
<0d66bf24-2ded-cd98-ec55-945e01b436d0@voskuil.org>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 16 Nov 2016 18:47:33 -0800
Message-ID: <CAPg+sBhYfoCtpzQAQXtQ4r2zVtC3Exwe55o-BF+=Eez1cb==4w@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=94eb2c1246442f3419054176366b
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: Thu, 17 Nov 2016 02:47:36 -0000
--94eb2c1246442f3419054176366b
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil <eric@voskuil.org> wrote:
> On 11/16/2016 05:50 PM, Pieter Wuille wrote:
>
> > So are checkpoints good now?
> > I believe we should get rid of checkpoints because they seem to be
> misunderstood as a security feature rather than as an optimization.
>
> Or maybe because they place control of the "true chain" in the hands of
> those selecting the checkpoints? It's not a great leap for the parties
> distributing the checkpoints to become the central authority.
>
Yes, they can be used to control the "true chain", and this has happened
with various forks. But developers inevitably have this possibility, if you
ignore review. If review is good enough to catch unintended consensus
changes, it is certainly enough to catch the introduction of an invalid
checkpoint. The risk you point out is real, but the way to deal with it is
good review and release practices.
I wish we had never used checkpoints the way we did, but here we are.
Because of this, I want to get rid of them. However, It's not because I
think they offer an excessive power to developers - but because they're
often perceived this way (partially as a result of how they've been abused
in other systems).
> I recommend users of our node validate the full chain without
> checkpoints and from that chain select their own checkpoints and place
> them into config. From that point forward they can apply the
> optimization. Checkpoints should never be hardcoded into the source.
>
Having users with the discipline you suggest would be wonderful to have. I
don't think it's very realistic, though, and I fear that the result would
be that everyone copies their config from one or a few websites "because
that's what everyone uses".
> I don't think buried softforks have that problem.
>
> I find "buried softfork" a curious name as you are using it. You seem to
> be implying that this type of change is itself a softfork as opposed to
> a hardfork that changes the activation of a softfork. It was my
> understanding that the term referred to the 3 softforks that were being
> "buried", or the proposal, but not the burial itself.
>
I do not consider the practice of "buried softforks" to be a fork at all.
It is a change that modifies the validity of a theoretically construable
chain from invalid to valid. However, a reorganization to that theoretical
chain itself is likely already impossible due to the vast number of blocks
to rewind, and economic damage that is far greater than chain divergence
itself.
> Nevertheless, this proposal shouldn't have "that problem" because it is
> clearly neither a security feature nor an optimization. That is the
> first issue that needs to be addressed.
It is clearly not a security feature, agreed. But how would you propose to
avoid the ISM checks for BIP34 and BIP66 all the time? I feel this approach
is a perfectly reasonable choice for code that likely won't ever affect the
valid chain again.
Cheers,
--
Pieter
--94eb2c1246442f3419054176366b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil <span dir=3D=
"ltr"><<a href=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskui=
l.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/16/2016 05:=
50 PM, Pieter Wuille wrote:<br></span></blockquote><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">
</span><span class=3D"">> So are checkpoints good now?<br>
> I believe we should get rid of checkpoints because they seem to be<br>
misunderstood as a security feature rather than as an optimization.<br>
<br>
</span>Or maybe because they place control of the "true chain" in=
the hands of<br>
those selecting the checkpoints? It's not a great leap for the parties<=
br>
distributing the checkpoints to become the central authority.<br></blockquo=
te><div><br></div><div>Yes, they can be used to control the "true chai=
n", and this has happened with various forks. But developers inevitabl=
y have this possibility, if you ignore review. If review is good enough to =
catch unintended consensus changes, it is certainly enough to catch the int=
roduction of an invalid checkpoint. The risk you point out is real, but the=
way to deal with it is good review and release practices.<br><br></div><di=
v>I wish we had never used checkpoints the way we did, but here we are. Bec=
ause of this, I want to get rid of them. However, It's not because I th=
ink they offer an excessive power to developers - but because they're o=
ften perceived this way (partially as a result of how they've been abus=
ed in other systems).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
I recommend users of our node validate the full chain without<br>
checkpoints and from that chain select their own checkpoints and place<br>
them into config. From that point forward they can apply the<br>
optimization. Checkpoints should never be hardcoded into the source.<br></b=
lockquote><div><br></div>Having users with the discipline you suggest would=
be wonderful to have. I don't think it's very realistic, though, a=
nd I fear that the result would be that everyone copies their config from o=
ne or a few websites "because that's what everyone uses".<spa=
n class=3D""><br><br></span><span class=3D""></span></div><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
> I don't think buried softforks have that problem.<br>
<br>
</span>I find "buried softfork" a curious name as you are using i=
t. You seem to<br>
be implying that this type of change is itself a softfork as opposed to<br>
a hardfork that changes the activation of a softfork. It was my<br>
understanding that the term referred to the 3 softforks that were being<br>
"buried", or the proposal, but not the burial itself.<br></blockq=
uote><div><br></div><div>I do not consider the practice of "buried sof=
tforks" to be a fork at all. It is a change that modifies the validity=
of a theoretically construable chain from invalid to valid. However, a reo=
rganization to that theoretical chain itself is likely already impossible d=
ue to the vast number of blocks to rewind, and economic damage that is far =
greater than chain divergence itself.<br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
Nevertheless, this proposal shouldn't have "that problem" bec=
ause it is<br>
clearly neither a security feature nor an optimization. That is the<br>
first issue that needs to be addressed.</blockquote><div><br></div><div>It =
is clearly not a security feature, agreed. But how would you propose to avo=
id the ISM checks for BIP34 and BIP66 all the time? I feel this approach is=
a perfectly reasonable choice for code that likely won't ever affect t=
he valid chain again.<br><br></div><div>Cheers,<br><br></div><div>-- <br></=
div><div>Pieter<br>=C2=A0<br></div></div></div></div>
--94eb2c1246442f3419054176366b--
|
