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
|
Return-Path: <gubatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98711BC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 22:25:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAF5C217
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 22:25:16 +0000 (UTC)
Received: by mail-wm0-f67.google.com with SMTP id u144so996184wmu.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 14:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=png6OZopOKFKn0tOBPrxZ917DxOoXGA5khsDq4snc2k=;
b=WX1VlGHgD157ji2l1lnTotPfxNb4Xqvt/gIKdzDic8N31ODNP9J0dYVmGmMvDGE3Po
N5JNgayJM8/MtjssxXlLMinCxuA0ggnZhoTMJ86iIa+fWQzAHwZp369Fg62+4mowGb2a
srtwLx43rZQhEQmSGREZsgfqK98XJBaASvYV/63iogOqwAudHKvXT2SWXfJ/UgsLdC5Y
ijWgx+tVHFMj3mJqcX96zfgR5naim44OdJT/MuhurugEIrXK6Sw9kik8xRX18DV3UpUO
8Vssw6Tfu1CYcHc1kIp6EG672MkgXRY1RF7vnKa//hGsQ6o7seWmDcx+YYnrwgFs+Px8
ZPmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=png6OZopOKFKn0tOBPrxZ917DxOoXGA5khsDq4snc2k=;
b=aRDFhW8fw5yezg0f1FUbW+KLYApFrs5/aotBCEmwB6dTXoLxOWe4UM9UJ+txkt6ENg
Vwrdzf9VONKNAGAIbggMRZTZEKGDvTAcO4QtX+YeQJC2t97XSaSxyTmWOVnuhpIPnIT8
kxRa5c1AmGJhFQSUCYgvry7V+a0Wp+aucxPPMe9btfYhexfgRKHnqkZ5yDvgUCPrt7vr
zEdpMfR9jn+xHMAh56ZKJjG8WIUeQ5ZDKF9joIy6lUHc6OYrgmlrVtK8oBGVMUjTnpGw
fef+EJKCsYYtflSu4OOmQ8hx1vEuzgAWkIWOou+3hX0DfuA1MzAPUT2Y/cAwG11Otw6A
5jfw==
X-Gm-Message-State: AKaTC025ioI7DgOzNzYtK/9FyscRlgpAEkXli6LkCuezzj8mTb3WC+ZooqUv/5HxWry5twX0kfqVcxuuzYRL1A==
X-Received: by 10.25.203.139 with SMTP id b133mr1203336lfg.124.1481840715297;
Thu, 15 Dec 2016 14:25:15 -0800 (PST)
MIME-Version: 1.0
References: <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
<615c88d2a1263810923705c170b25d33@112bit.com>
<CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
In-Reply-To: <CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Thu, 15 Dec 2016 22:25:04 +0000
Message-ID: <CADZB0_Z_J5ebAXbr66MvizrQ8YJOh5=rFhuuFWkVPtS82PF3iQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
jg@112bit.com
Content-Type: multipart/alternative; boundary=94eb2c1a1dbe72fb190543b9ed32
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
X-Mailman-Approved-At: Thu, 15 Dec 2016 22:33:57 +0000
Subject: Re: [bitcoin-dev] Planned Obsolescence
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, 15 Dec 2016 22:25:17 -0000
--94eb2c1a1dbe72fb190543b9ed32
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Perhaps if there were a message that would nag your stdout or log output
letting you know there's a new version available, or N more versions
available and that you might be missing out on X security patches, Y
protocol improvements, depending on how far back you are, you'd be tempted
to upgrade, works for me in Ubuntu every time I log to my servers and I see
how far behind I am in terms of available updates.
Other thing done in open source projects to encourage updates, is to
automatically distribute (download) the patches and let the node operator
know an update has been downloaded for them, and let them know they're just
one step away from applying such update.
We do this for our bittorrent client. We don't ever want to do automatic
upgrades of our network, however, we want to make it painless to update.
For Bitcoin this could be done for the official binary distribution, would
not be an option for those that build from source.
On Thu, Dec 15, 2016 at 11:49 AM Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Older node versions may generate issues because some upgrades will make
> > several of the nodes running older protocol versions obsolete and or
> > incompatible. There may be other hard to predict behaviors on older
> versions
> > of the client.
>
> Hard to predict or not, you can't force people to run newer software.
>
> > In order to avoid such wide fragmentation of "Bitcoin Core=E2=80=9D nod=
e versions
> > and to help there be a more predictable protocol improvement process, I
> > consider it worth it to analyze introducing some planned obsolescence i=
n
> > each new version. In the last year we had 4 new versions so if each
> version
> > is valid for about 1 year (52560 blocks) this may be a reasonable time
> frame
> > for node operators to upgrade. If a node does not upgrade it will stop
> > working instead of participating in the network with an outdated protoc=
ol
> > version.
>
> When you introduce anti-features like this in free software they can
> be trivially removed and they likely will.
>
> > These changes may also simplify the developer's jobs in some cases by
> > avoiding them having to deal with ancient versions of the client.
>
> There's a simpler solution for this which is what is being done now:
> stop maintaining and giving support for older versions.
> There's limited resources and developers are rarely interested in
> fixing bugs for very old versions. Users shouldn't expect things to be
> backported to old versions (if developers do it and there's enough
> testing, there's no reason not to do more releases of old versions, it
> is just rarely the case).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c1a1dbe72fb190543b9ed32
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Perhaps if there were a message that would nag your stdout=
or log output letting you know there's a new version available, or N m=
ore versions available and that you might be missing out on X security patc=
hes, Y protocol improvements, depending on how far back you are, you'd =
be tempted to upgrade, works for me in Ubuntu every time I log to my server=
s and I see how far behind I am in terms of available updates.<br><br>Other=
thing done in open source projects to encourage updates, is to automatical=
ly distribute (download) the patches and let the node operator know an upda=
te has been downloaded for them, and let them know they're just one ste=
p away from applying such update. <br>We do this for our bittorrent client.=
We don't ever want to do automatic upgrades of our network, however, w=
e want to make it painless to update.<br><br>For Bitcoin this could be done=
for the official binary distribution, would not be an option for those tha=
t build from source.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Thu, Dec 15, 2016 at 11:49 AM Jorge Tim=C3=B3n via bitcoin-dev <<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu=
, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev<br class=3D"gmai=
l_msg">
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail=
_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote=
:<br class=3D"gmail_msg">
> Older node versions may generate issues because some upgrades will mak=
e<br class=3D"gmail_msg">
> several of the nodes running older protocol versions obsolete and or<b=
r class=3D"gmail_msg">
> incompatible. There may be other hard to predict behaviors on older ve=
rsions<br class=3D"gmail_msg">
> of the client.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Hard to predict or not, you can't force people to run newer software.<b=
r class=3D"gmail_msg">
<br class=3D"gmail_msg">
> In order to avoid such wide fragmentation of "Bitcoin Core=E2=80=
=9D node versions<br class=3D"gmail_msg">
> and to help there be a more predictable protocol improvement process, =
I<br class=3D"gmail_msg">
> consider it worth it to analyze introducing some planned obsolescence =
in<br class=3D"gmail_msg">
> each new version. In the last year we had 4 new versions so if each ve=
rsion<br class=3D"gmail_msg">
> is valid for about 1 year (52560 blocks) this may be a reasonable time=
frame<br class=3D"gmail_msg">
> for node operators to upgrade. If a node does not upgrade it will stop=
<br class=3D"gmail_msg">
> working instead of participating in the network with an outdated proto=
col<br class=3D"gmail_msg">
> version.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
When you introduce anti-features like this in free software they can<br cla=
ss=3D"gmail_msg">
be trivially removed and they likely will.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> These changes may also simplify the developer's jobs in some cases=
by<br class=3D"gmail_msg">
> avoiding them having to deal with ancient versions of the client.<br c=
lass=3D"gmail_msg">
<br class=3D"gmail_msg">
There's a simpler solution for this which is what is being done now:<br=
class=3D"gmail_msg">
stop maintaining and giving support for older versions.<br class=3D"gmail_m=
sg">
There's limited resources and developers are rarely interested in<br cl=
ass=3D"gmail_msg">
fixing bugs for very old versions. Users shouldn't expect things to be<=
br class=3D"gmail_msg">
backported to old versions (if developers do it and there's enough<br c=
lass=3D"gmail_msg">
testing, there's no reason not to do more releases of old versions, it<=
br class=3D"gmail_msg">
is just rarely the case).<br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div>
--94eb2c1a1dbe72fb190543b9ed32--
|
