Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 98711BC1 for ; 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 ; Thu, 15 Dec 2016 22:25:16 +0000 (UTC) Received: by mail-wm0-f67.google.com with SMTP id u144so996184wmu.0 for ; 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: <615c88d2a1263810923705c170b25d33@112bit.com> In-Reply-To: From: Angel Leon Date: Thu, 15 Dec 2016 22:25:04 +0000 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Bitcoin Protocol Discussion , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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
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.

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.
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.

For Bitcoin this could be done= for the official binary distribution, would not be an option for those tha= t build from source.

O= n Thu, Dec 15, 2016 at 11:49 AM Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.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 mak= e
> several of the nodes running older protocol versions obsolete and or > incompatible. There may be other hard to predict behaviors on older ve= rsions
> 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 node versions
> and to help there be a more predictable protocol improvement process, = I
> consider it worth it to analyze introducing some planned obsolescence = in
> each new version. In the last year we had 4 new versions so if each ve= rsion
> 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 proto= col
> 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<= br class=3D"gmail_msg"> 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<= br class=3D"gmail_msg"> is just rarely the case).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--94eb2c1a1dbe72fb190543b9ed32--