path: root/6c/42a124cee26db9910b27f58075ee5fbae6b8eb

Return-Path: <criley@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F37D8932
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Dec 2016 20:50:56 +0000 (UTC)
Received: by mail-wj0-f176.google.com with SMTP id tk12so135051642wjb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
	<615c88d2a1263810923705c170b25d33@112bit.com>
	<CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
	<CAEM=y+Ws-2_mpZQfE1BD8dnmkcBFsXK8Pd3ZvX=e9R_4bj4qng@mail.gmail.com>
	<10231F2A-32C3-4E19-934B-C83E595DDBEB@mattcorallo.com>
From: Chris Riley <criley@gmail.com>
Date: Sun, 18 Dec 2016 15:50:53 -0500
Message-ID: <CAL5BAw3R_Kd_KSk4j5WeF09s7KTAc5-O1b4i+ZvygMpuqJaMuw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
> ><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 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

<div dir=3D"ltr">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<div><br></div><div>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&#39;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.</div><div><br=
></div><div>Chris</div><div><br></div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Sun, Dec 18, 2016 at 5:34 AM, Matt Corallo vi=
a bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One thing which hasn=
&#39;t been addressed yet in this thread is developer centralization. Unlik=
e other applications we want to ensure that it&#39;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.<br>
<br>
Matt<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr=
>linuxfoundation.org</a>&gt; wrote:<br>
&gt;I assume this has been well discussed in at some point in the Bitcoin<b=
r>
&gt;community, so I apologize if I&#39;m repeating old ideas.<br>
&gt;<br>
&gt;Problem exploitable nodes:<br>
&gt;It is plausible that people running these versions of bitcoind may not<=
br>
&gt;be applying patches. Thus, these nodes may be vulnerable to known<br>
&gt;exploits. I would hope none of these nodes are gateway nodes for<br>
&gt;miners, web wallets or exchanges. How difficult would it be to crawl<br=
>
&gt;the network to find vulnerable nodes and exploit them? What percentage<=
br>
&gt;of the network is running vulnerable versions of bitcoind?<br>
&gt;<br>
&gt;Problem eclipsable nodes:<br>
&gt;Currently a bitcoind node disconnects from any node with a version<br>
&gt;below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse<=
br>
&gt;attack because they are partitioned from the newer nodes, especially<br=
>
&gt;when they are &quot;freshly obsolete&quot;. I have not examined how pro=
tocol<br>
&gt;versioning works in detail so I could be missing something.<br>
&gt;<br>
&gt;One option could be that after a grace period:<br>
&gt;1. to still connect to obsolete nodes and even to transmit<br>
&gt;blockheaders,<br>
&gt;2. but to stop sending the full-blocks and transactions to these<br>
&gt;nodes, thereby alerting the operator that something is wrong and<br>
&gt;causing them to upgrade.<br>
&gt;It may make sense to create this as a rule, if your longest chain<br>
&gt;consists of only blockheaders and no one will tell you the<br>
&gt;transactions for over 1000 blocks you are obsolete, spit out an error<b=
r>
&gt;message and shutdown.<br>
&gt;<br>
&gt;This would not address the issue of alt-coins which are forked from<br>
&gt;old vulnerable versions of bitcoind, but that is probably out of<br>
&gt;scope.<br>
&gt;<br>
&gt;On Thu, Dec 15, 2016 at 1:48 PM, Jorge Tim=C3=B3n via bitcoin-dev<br>
&gt;&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev<b=
r>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt; Older node versions may generate issues because some upgrades =
will<br>
&gt;make<br>
&gt;&gt;&gt; several of the nodes running older protocol versions obsolete =
and or<br>
&gt;&gt;&gt; incompatible. There may be other hard to predict behaviors on =
older<br>
&gt;versions<br>
&gt;&gt;&gt; of the client.<br>
&gt;&gt;<br>
&gt;&gt; Hard to predict or not, you can&#39;t force people to run newer so=
ftware.<br>
&gt;&gt;<br>
&gt;&gt;&gt; In order to avoid such wide fragmentation of &quot;Bitcoin Cor=
e=E2=80=9D node<br>
&gt;versions<br>
&gt;&gt;&gt; and to help there be a more predictable protocol improvement<b=
r>
&gt;process, I<br>
&gt;&gt;&gt; consider it worth it to analyze introducing some planned<br>
&gt;obsolescence in<br>
&gt;&gt;&gt; each new version. In the last year we had 4 new versions so if=
 each<br>
&gt;version<br>
&gt;&gt;&gt; is valid for about 1 year (52560 blocks) this may be a reasona=
ble<br>
&gt;time frame<br>
&gt;&gt;&gt; for node operators to upgrade. If a node does not upgrade it w=
ill<br>
&gt;stop<br>
&gt;&gt;&gt; working instead of participating in the network with an outdat=
ed<br>
&gt;protocol<br>
&gt;&gt;&gt; version.<br>
&gt;&gt;<br>
&gt;&gt; When you introduce anti-features like this in free software they c=
an<br>
&gt;&gt; be trivially removed and they likely will.<br>
&gt;&gt;<br>
&gt;&gt;&gt; These changes may also simplify the developer&#39;s jobs in so=
me cases<br>
&gt;by<br>
&gt;&gt;&gt; avoiding them having to deal with ancient versions of the clie=
nt.<br>
&gt;&gt;<br>
&gt;&gt; There&#39;s a simpler solution for this which is what is being don=
e now:<br>
&gt;&gt; stop maintaining and giving support for older versions.<br>
&gt;&gt; There&#39;s limited resources and developers are rarely interested=
 in<br>
&gt;&gt; fixing bugs for very old versions. Users shouldn&#39;t expect thin=
gs to<br>
&gt;be<br>
&gt;&gt; backported to old versions (if developers do it and there&#39;s en=
ough<br>
&gt;&gt; testing, there&#39;s no reason not to do more releases of old vers=
ions,<br>
&gt;it<br>
&gt;&gt; is just rarely the case).<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;_____________________________<wbr>__________________<br>
&gt;bitcoin-dev mailing list<br>
&gt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
&gt;<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.<wbr>linuxfoundation=
.org/mailman/<wbr>listinfo/bitcoin-dev</a><br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--047d7bf198689776350543f4f5ac--