public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jg@112bit.com
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Planned Obsolescence
Date: Wed, 14 Dec 2016 20:38:09 -0700	[thread overview]
Message-ID: <615c88d2a1263810923705c170b25d33@112bit.com> (raw)
In-Reply-To: <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>

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


       reply	other threads:[~2016-12-15  3:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
2016-12-15  3:38 ` jg [this message]
2016-12-15 18:12   ` [bitcoin-dev] Planned Obsolescence Aymeric Vitte
2016-12-15 18:48   ` Jorge Timón
2016-12-15 22:25     ` Angel Leon
2016-12-15 22:44     ` Ethan Heilman
2016-12-18 10:34       ` Matt Corallo
2016-12-18 20:50         ` Chris Riley
2016-12-18 20:07   ` Alice Wonder
2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
2016-12-19  8:13       ` Alice Wonder
2016-12-21 18:33         ` Marco Falke
2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
2016-12-19  6:39       ` Btc Drak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=615c88d2a1263810923705c170b25d33@112bit.com \
    --to=jg@112bit.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox