Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F37D8932 for ; Sun, 18 Dec 2016 20:50:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wj0-f176.google.com (mail-wj0-f176.google.com [209.85.210.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 73B641FD for ; Sun, 18 Dec 2016 20:50:56 +0000 (UTC) Received: by mail-wj0-f176.google.com with SMTP id tk12so135051642wjb.3 for ; Sun, 18 Dec 2016 12:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hRjBG7hyUZgc/t3+WuHpFbvK08n1AGa2ChQwCdQMPjk=; b=PxkqvoKnVl38zYXNoDjKxFEb9nYWsV+l8crge9+MPglNsdrdBD9OJP5lkCsPN31gGN +SYHjV5zmypw9HkCATnDi+a9QhnBsGTOGQEHlF4GM6p2hrV71OigBcVEhkUQZRAZM1Vf tuN0OeNz3x8Mgt3xCdSkltRwAeJ/nt9QeqqkaC310VYGNd9HStYrD3iqKfELosO853Sp DzPKaXhN9yaXttPFBJFzf4uR4AgK+GOAzHBurNxJBLv6jrn2qnMGyoC/JDz8oPMxMJeQ rTZbZwgK5nWtPxV03jhADfskNZjRK2EM13PjjWB/a08twTQLotVevcR4DmPL0Lv5gYNA uAwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hRjBG7hyUZgc/t3+WuHpFbvK08n1AGa2ChQwCdQMPjk=; b=GuZcagLj9Ooa5nzm5d0B/Pg1s3k9eNsr0Gsn9PZvkA+1vSqMwcF+XCMCQCAgUt3TmL EI82YrcJHzv9zGIj1dRqHWMl3l9hfFli4hGGyQ2X2veG5dhQiqhx0Q9J3gQKZsn8Ixjr P8/EPMVgQa1MLj8Y9JQArqA21JrDGni8wa2WlHu1SstbW6QFgRf+W3udlefVJiNxmFEA j0ONN96xRJszjj1Uxi01jz/Y1bio0qdf0IWADIZMo5OWXFfHenvkEcKQxA3Yp7Hydapt eSntOS0X6mtDvmCACQZxBVBNr6KhuYrAHzBZtpLhHsKBQRjXpfwDM6kFAyARmw0DiliO jRFQ== X-Gm-Message-State: AIkVDXLBVbW9tIaqWerQn1gPQwmiRHaSo7w7S7o/tzzMrKyOhsbzd0d6iyLCXZjBnZmF2ppeaYKoK1emTdU26w== X-Received: by 10.194.88.201 with SMTP id bi9mr10699338wjb.71.1482094254976; Sun, 18 Dec 2016 12:50:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.153.2 with HTTP; Sun, 18 Dec 2016 12:50:53 -0800 (PST) In-Reply-To: <10231F2A-32C3-4E19-934B-C83E595DDBEB@mattcorallo.com> References: <615c88d2a1263810923705c170b25d33@112bit.com> <10231F2A-32C3-4E19-934B-C83E595DDBEB@mattcorallo.com> From: Chris Riley Date: Sun, 18 Dec 2016 15:50:53 -0500 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=047d7bf198689776350543f4f5ac 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: Sun, 18 Dec 2016 21:35:39 +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: Sun, 18 Dec 2016 20:50:58 -0000 --047d7bf198689776350543f4f5ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that finding the right line is difficult and purposefully crippling (too strong a term?) the software is not necessarily the best way to encourage long term adoption. For example, I ran version 0.3.x from July/August 2010 for several years on a miner without upgrading to anything higher than the 0.3.24 release since the usage pattern on that machine didn't require it. It might have been to the ~0.7.0 release, I am not sure when I finally upgraded it. On a machine that had my wallet, I kept it updated, but forcing upgrades may not be the best plan given that hard forks should be few and far between. Security updates, are important, but leaving it up to the operator of the node to determine when to upgrade is an important feature. Chris On Sun, Dec 18, 2016 at 5:34 AM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > One thing which hasn't been addressed yet in this thread is developer > centralization. Unlike other applications we want to ensure that it's not > only possible for users to refuse an upgrade, but easy. While this by no > means lessens the retirement that users run up to date software for > security reasons, finding the right line to draw is difficult. > > Matt > > On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >I assume this has been well discussed in at some point in the Bitcoin > >community, so I apologize if I'm repeating old ideas. > > > >Problem exploitable nodes: > >It is plausible that people running these versions of bitcoind may not > >be applying patches. Thus, these nodes may be vulnerable to known > >exploits. I would hope none of these nodes are gateway nodes for > >miners, web wallets or exchanges. How difficult would it be to crawl > >the network to find vulnerable nodes and exploit them? What percentage > >of the network is running vulnerable versions of bitcoind? > > > >Problem eclipsable nodes: > >Currently a bitcoind node disconnects from any node with a version > >below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse > >attack because they are partitioned from the newer nodes, especially > >when they are "freshly obsolete". I have not examined how protocol > >versioning works in detail so I could be missing something. > > > >One option could be that after a grace period: > >1. to still connect to obsolete nodes and even to transmit > >blockheaders, > >2. but to stop sending the full-blocks and transactions to these > >nodes, thereby alerting the operator that something is wrong and > >causing them to upgrade. > >It may make sense to create this as a rule, if your longest chain > >consists of only blockheaders and no one will tell you the > >transactions for over 1000 blocks you are obsolete, spit out an error > >message and shutdown. > > > >This would not address the issue of alt-coins which are forked from > >old vulnerable versions of bitcoind, but that is probably out of > >scope. > > > >On Thu, Dec 15, 2016 at 1:48 PM, Jorge Tim=C3=B3n via bitcoin-dev > > 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 n= ode > >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 > >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 > >protocol > >>> 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 > >_______________________________________________ > >bitcoin-dev mailing list > >bitcoin-dev@lists.linuxfoundation.org > >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --047d7bf198689776350543f4f5ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that finding the right line is difficult and purpo= sefully crippling (too strong a term?) the software is not necessarily the = best way to encourage long term adoption. =C2=A0

For exa= mple, I ran version 0.3.x from July/August 2010 for several years on a mine= r without upgrading to anything higher than the 0.3.24 release since the us= age pattern on that machine didn't require it.=C2=A0 It might have been= to the ~0.7.0 release, I am not sure when I finally upgraded it.=C2=A0 On = a machine that had my wallet, I kept it updated, but forcing upgrades may n= ot be the best plan given that hard forks should be few and far between.=C2= =A0 Security updates, are important, but leaving it up to the operator of t= he node to determine when to upgrade is an important feature.
Chris


=
On Sun, Dec 18, 2016 at 5:34 AM, Matt Corallo vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
One thing which hasn= 't been addressed yet in this thread is developer centralization. Unlik= e other applications we want to ensure that it's not only possible for = users to refuse an upgrade, but easy. While this by no means lessens the re= tirement that users run up to date software for security reasons, finding t= he right line to draw is difficult.

Matt

On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>I assume this has been well discussed in at some point in the Bitcoin >community, so I apologize if I'm repeating old ideas.
>
>Problem exploitable nodes:
>It is plausible that people running these versions of bitcoind may not<= br> >be applying patches. Thus, these nodes may be vulnerable to known
>exploits. I would hope none of these nodes are gateway nodes for
>miners, web wallets or exchanges. How difficult would it be to crawl >the network to find vulnerable nodes and exploit them? What percentage<= br> >of the network is running vulnerable versions of bitcoind?
>
>Problem eclipsable nodes:
>Currently a bitcoind node disconnects from any node with a version
>below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse<= br> >attack because they are partitioned from the newer nodes, especially >when they are "freshly obsolete". I have not examined how pro= tocol
>versioning works in detail so I could be missing something.
>
>One option could be that after a grace period:
>1. to still connect to obsolete nodes and even to transmit
>blockheaders,
>2. but to stop sending the full-blocks and transactions to these
>nodes, thereby alerting the operator that something is wrong and
>causing them to upgrade.
>It may make sense to create this as a rule, if your longest chain
>consists of only blockheaders and no one will tell you the
>transactions for over 1000 blocks you are obsolete, spit out an error >message and shutdown.
>
>This would not address the issue of alt-coins which are forked from
>old vulnerable versions of bitcoind, but that is probably out of
>scope.
>
>On Thu, Dec 15, 2016 at 1:48 PM, Jorge Tim=C3=B3n via bitcoin-dev
><bitcoin-de= v@lists.linuxfoundation.org> wrote:
>> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev >> <bitco= in-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 so= ftware.
>>
>>> In order to avoid such wide fragmentation of "Bitcoin Cor= e=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
>version
>>> is valid for about 1 year (52560 blocks) this may be a reasona= ble
>time frame
>>> for node operators to upgrade. If a node does not upgrade it w= ill
>stop
>>> working instead of participating in the network with an outdat= ed
>protocol
>>> version.
>>
>> When you introduce anti-features like this in free software they c= an
>> be trivially removed and they likely will.
>>
>>> These changes may also simplify the developer's jobs in so= me cases
>by
>>> avoiding them having to deal with ancient versions of the clie= nt.
>>
>> There's a simpler solution for this which is what is being don= e 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 thin= gs to
>be
>> backported to old versions (if developers do it and there's en= ough
>> testing, there's no reason not to do more releases of old vers= ions,
>it
>> is just rarely the case).
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@li= sts.linuxfoundation.org
>https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--047d7bf198689776350543f4f5ac--