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
|
Return-Path: <eth3rs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C2DD3BAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 22:45:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com
[209.85.217.193])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DBA3119D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 22:45:36 +0000 (UTC)
Received: by mail-ua0-f193.google.com with SMTP id 20so2441491uak.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Dec 2016 14:45:36 -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
:cc:content-transfer-encoding;
bh=os/KsL62F2QaSrXoiFyayiFLcK0HyG8MtO5od8nUrJ8=;
b=tXL7sJJu+3h9D/+aBp94MnCpyedFsrUTEhsxvf4fQDf3YrMs951UDmHt1KkfgbJFp8
GlsNPO57eKA9FS9wuuE6MlacexSe25gY4keCbi9z0ATaFTy1gWee1KsSJFoTmS7U7iO1
0A7aYfdX/gJAWs0u+FUwpRWeZ3BfH9kIZ1vknOhjeLLKeNccSAD5mgdPZPPX3bFsMfqs
YQDPTM3ZDirhyFXRuFuI3Ig4CWJF05Ba8b71pICQDDVg/O2QvB2MPAHFS8grAtqGrU7j
vMWJ+kHaizs0o+TqHtngFYinfzQYPbk1FEuk+KTUaYWKAqJEXb7IBU2AXFJChd0gz04s
4iLg==
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:cc:content-transfer-encoding;
bh=os/KsL62F2QaSrXoiFyayiFLcK0HyG8MtO5od8nUrJ8=;
b=qNg77Pj0CXFYLcgDY8RRRT4u970DyWQmh5RF+1ZaoPIoPNGJ6nZPcTEGk95Uf2Y5iU
zna/iaF/IJn/fapzEpWx5iy/rcucJVHaWhLNeoNwRuq+cNdZt00Ajmr3nAXu/ndzBEso
Z9YX5dVq/RoFPYQityGXvI/VBxw38WepOetnIIvPq2faK7aHCQs192mXFnyHjnSzhI9e
T37yOk2yt2lthGWc/vhFRl91ndqz9+1GjUo2nFq2DfX3sSnf9UaemUKDT3ZXO2htOK+C
cT0ONFKlvQUMi2FycolfMnDK41CwONOuAX2hHBLoDZG5YBVfeAdGy4xyofP6vRCUpdyi
gHYA==
X-Gm-Message-State: AKaTC00N7aQOojQ940VHQ5YYparJT/jQf5nUx3R95+IiZPXDdN6tQkLmlk8f48Ubh0cgX1rKIL7mxlRwQS/pPQ==
X-Received: by 10.176.68.68 with SMTP id m62mr4538740uam.65.1481841936029;
Thu, 15 Dec 2016 14:45:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.6.66 with HTTP; Thu, 15 Dec 2016 14:44:55 -0800 (PST)
In-Reply-To: <CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
References: <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
<615c88d2a1263810923705c170b25d33@112bit.com>
<CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Thu, 15 Dec 2016 17:44:55 -0500
Message-ID: <CAEM=y+Ws-2_mpZQfE1BD8dnmkcBFsXK8Pd3ZvX=e9R_4bj4qng@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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:48:22 +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:45:39 -0000
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 vers=
ions
>> 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 vers=
ion
>> is valid for about 1 year (52560 blocks) this may be a reasonable time f=
rame
>> for node operators to upgrade. If a node does not upgrade it will stop
>> working instead of participating in the network with an outdated protoco=
l
>> 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
|
