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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B6046B60
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 10:35:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9C4EA1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 10:35:15 +0000 (UTC)
Received: from [IPv6:2607:fb90:a444:c025:8c9e:4ff5:473b:ddd0] (unknown
[172.58.32.214])
by mail.bluematt.me (Postfix) with ESMTPSA id B961E135DCC;
Sun, 18 Dec 2016 10:35:11 +0000 (UTC)
In-Reply-To: <CAEM=y+Ws-2_mpZQfE1BD8dnmkcBFsXK8Pd3ZvX=e9R_4bj4qng@mail.gmail.com>
References: <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
<615c88d2a1263810923705c170b25d33@112bit.com>
<CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
<CAEM=y+Ws-2_mpZQfE1BD8dnmkcBFsXK8Pd3ZvX=e9R_4bj4qng@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Sun, 18 Dec 2016 10:34:43 +0000
To: Ethan Heilman <eth3rs@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Ethan Heilman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
=?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@jtimon.cc>
Message-ID: <10231F2A-32C3-4E19-934B-C83E595DDBEB@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 10:35:16 -0000
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ón 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” 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 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
|
