[bitcoin-dev] Planned Obsolescence

[Juan Garavaglia via bitcoin-dev]

Today according to the stats at https://bitnodes.21.co/nodes/ the top 10
Bitcoin running node versions are:

1.
_Version Satoshi:0.13.1
_Nodes 2071
_38.97%


2.
_Version Satoshi:0.12.1
_Nodes 1022
_19.23%


3.
Satoshi:0.13.0
_Nodes 604
_11.36%


4.
Bitcoin Unlimited:0.12.1
_Nodes 373
_7.02%


5.
Satoshi:0.11.2
_Nodes 183
_3.44%


6.
Satoshi:0.12.0
_Nodes 131
_2.46%


7. Satoshi:0.13.99
_Nodes 122
_2.30%


8.
Satoshi:0.11.0
_Nodes 87
_1.64%


9.
BTCC:0.13.1
_Nodes 53
_1.00%


10.
Satoshi:0.10.2
_Nodes 52
_0.98%


Other
_Nodes 617
_11.61%


There are 75 different versions of visible nodes on the network.

More than 30% of the nodes running Bitcoin Core are running versions
older than 0.13.0.

For reasons I am unable to determine a significant number of node
operators do not upgrade their clients.

I also know newer versions require the same or fewer hardware resources
to run than the same network requirements as older versions of the
client.

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.

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.

These changes may also simplify the developer's jobs in some cases by
avoiding them having to deal with ancient versions of the client.

Regards
Juan Garavaglia

[Aymeric Vitte via bitcoin-dev]

Maybe there are still some advantages but I don't know why this is not
considered as a major issue by the bitcoin community for the future and
why this looks to be never discussed:

- the size of the bitcoin network in terms of full nodes is ridiculous
and this is continuously decreasing, we cannot consider the bitcoin
network as a decentralized p2p network, what you are proposing is
logical but will of course amplify the problem

Post by Juan Garavaglia via bitcoin-dev
For reasons I am unable to determine a significant number of node

operators do not upgrade their clients.

Why should they? What is the incentive for people to run full nodes and
upgrade? FYI I am part of the 2071 0.13.1 nodes for some good reasons
but will just shut it down when I am done, same for zcash (which as a
matter of fact I upgraded today since by some chance I noticed some
updates I was not aware of neither notified, just running it because I
need it from time to time and just don't kill it so I don't have to wait
for the restart process, maybe others are doing the same or just forgot
that they were running a full node)

Because, again, why should I or we maintain it/them?

I have looked at the proposals in the past (as well as the incentive
program) to reward those that are running full nodes but only found a
very few, never implemented (or even considered)

This is the very same for proposals allowing to start a full node from
zero in an acceptable timeframe (ie not 10 days in my case)

If the consensus is not to solve those two points and have a bitcoin
network controlled then it would be interesting to know why, so people
don't waste time trying to find solutions

Satoshi himself predicted that the full nodes will get centralized, I
think it's wrong, or in that case the bitcoin network cannot pretend to
be a decentralized immutable system (can be compared then to the Tor
network which does not pretend to be decentralized, because it is
centralized, and in addition does not encourage small nodes)

PS: IMHO the email notificiation system makes it difficult to follow
whom is answering to whom/what on this list compared to other lists
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

[Jorge Timón via bitcoin-dev]

On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
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.

Post by Juan Garavaglia via bitcoin-dev
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.

Post by Juan Garavaglia via bitcoin-dev
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).

[Angel Leon via bitcoin-dev]

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ón via bitcoin-dev <

Post by Jorge Timón via bitcoin-dev
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
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

Post by Juan Garavaglia via bitcoin-dev
of the client.

Hard to predict or not, you can't force people to run newer software.

Post by Juan Garavaglia via bitcoin-dev
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

Post by Juan Garavaglia via bitcoin-dev
is valid for about 1 year (52560 blocks) this may be a reasonable time

frame

Post by Juan Garavaglia via bitcoin-dev
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.

Post by Juan Garavaglia via bitcoin-dev
These changes may also simplify the developer's jobs in some cases by
avoiding them having to deal with ancient versions of the client.

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Ethan Heilman via bitcoin-dev]

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

Post by Jorge Timón via bitcoin-dev
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
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.

Post by Juan Garavaglia via bitcoin-dev
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.

Post by Juan Garavaglia via bitcoin-dev
These changes may also simplify the developer's jobs in some cases by
avoiding them having to deal with ancient versions of the client.

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Matt Corallo via bitcoin-dev]

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

Post by Ethan Heilman via bitcoin-dev
I assume this has been well discussed in at some point in the Bitcoin
community, so I apologize if I'm repeating old ideas.
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?
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.
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

Post by Jorge Timón via bitcoin-dev
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
Older node versions may generate issues because some upgrades will

make

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
several of the nodes running older protocol versions obsolete and or
incompatible. There may be other hard to predict behaviors on older

versions

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
of the client.

Hard to predict or not, you can't force people to run newer software.

Post by Juan Garavaglia via bitcoin-dev
In order to avoid such wide fragmentation of "Bitcoin Core” node

versions

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
and to help there be a more predictable protocol improvement

process, I

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
consider it worth it to analyze introducing some planned

obsolescence in

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
each new version. In the last year we had 4 new versions so if each

version

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
is valid for about 1 year (52560 blocks) this may be a reasonable

time frame

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
for node operators to upgrade. If a node does not upgrade it will

stop

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
working instead of participating in the network with an outdated

protocol

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
version.

When you introduce anti-features like this in free software they can
be trivially removed and they likely will.

Post by Juan Garavaglia via bitcoin-dev
These changes may also simplify the developer's jobs in some cases

by

Post by Jorge Timón via bitcoin-dev

Post by Juan Garavaglia via bitcoin-dev
avoiding them having to deal with ancient versions of the client.

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

Post by Jorge Timón via bitcoin-dev
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

Post by Jorge Timón via bitcoin-dev
is just rarely the case).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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