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
On 12/14/2016 07:38 PM, Juan Garavaglia via bitcoin-dev wrote:
For reasons I am unable to determine a significant number of node
operators do not upgrade their clients.
I almost did not update to 0.13.0 because the test suite was failing due
to python errors. How to fix them was posted on
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
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.
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,
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
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
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