The situation wrt 0.16.3 version highlights urgency of streamlining updates

[TwinPeeks]

Non updated full nodes could conceivably put the entire network at risk in the future. It could easily have been the case for this bug.

Updating to 0.16.3 from 0.16.0-2 for a non sophisticated Linux user may be prohibitively complex. Add to this the fact that a neophyte might not even become aware of the need to update at all in situations like the one encountered wrt the 0.16.3 update, and the urgency of streamlining the update process for end users seems to me to be pretty high.


Anyone have any thoughts or info on how much of a focus streamlining updates across different OS's and Linux Dsitributions currently is?

[Lauda]

1) The following is completely false:

Updating to 0.16.3 from 0.16.0-2 for a non sophisticated Linux user may be prohibitively complex.

This assumes that: a) Everyone uses Linux. b) That people using Linux don't have an easy method for updating. This is false; most non-sophisticated (if not ALL such users) are going to be using something like Ubuntu or Mint which has PPA and updating is trivial.
Updating Windows and Mac is very trivial. If you know how to install Bitcoin Core, then you should know how to update it.

Anyone have any thoughts or info on how much of a focus streamlining updates across different OS's and Linux Dsitributions currently is?

2) Updates can never be automatic for a decentralized system as such. Even adding something like a 'update available' notification system can open up more attack vectors and is (as always) prone to abuse.

[gmaxwell]

Non updated full nodes could conceivably put the entire network at risk in the future.

I don't agree.  If a user isn't accepting transactions on a node or mining with it, there is no particularly urgent reason to upgrade.  There are plenty of upgraded nodes on the network now.

The reason the notices encourage people to upgrade urgently is not because all actually need to, but because figuring out if you really need to or not is hard, so the best advice is for everyone to do it.

Updating to 0.16.3 from 0.16.0-2 for a non sophisticated Linux user may be prohibitively complex. Add to this the fact that a neophyte might not even become aware of the need to update at all in situations like the one encountered wrt the 0.16.3 update, and the urgency of streamlining the update process for end users seems to me to be pretty high.

That sounds like a reasonable concern but it has to be counterbalanced against the risk of a malicious update being deployed.  The fact that upgrades take a while makes me feel confident rather than frightened.

It's like the advice goes, "if you never miss a flight, you're probably wasting too much time in airports".  If we never had reason to wish updates went faster, we'd probably be excessively exposing users to the risk of a bad update.

If there ever were a really serious issue where updates had to happen or else, we'd be probably advising people to stop accepting confirmations and to potentially to turn their nodes off.

[Wind_FURY]

1) The following is completely false:

Updating to 0.16.3 from 0.16.0-2 for a non sophisticated Linux user may be prohibitively complex.

This assumes that: a) Everyone uses Linux. b) That people using Linux don't have an easy method for updating. This is false; most non-sophisticated (if not ALL such users) are going to be using something like Ubuntu or Mint which has PPA and updating is trivial.
Updating Windows and Mac is very trivial. If you know how to install Bitcoin Core, then you should know how to update it.

Plus most Linux users have always used or are always using the command line. I believe a simple step by step "howto" guide should be easy to follow for anyone who uses Linux.

Anyone have any thoughts or info on how much of a focus streamlining updates across different OS's and Linux Dsitributions currently is?

2) Updates can never be automatic for a decentralized system as such. Ever adding something like a 'update available' notification system can open up more attack vectors and is (as always) prone to abuse.

I was about to ask about that. Would it have been better, in this instance, if the alert system was still at the developers' disposal?

Non updated full nodes could conceivably put the entire network at risk in the future.

I don't agree.  If a user isn't accepting transactions on a node or mining with it, there is no particularly urgent reason to upgrade.  There are plenty of upgraded nodes on the network now.

But is that enough? There is about 80% of nodes that have'nt done the upgrade.

[Lauda]

Plus most Linux users have always used or are always using the command line. I believe a simple step by step "howto" guide should be easy to follow for anyone who uses Linux.

I believe that the majority of people running Linux nodes are split into two groups:
1) Those less familiar with it and/or running GUI - use PPA.
2) Those that are quite familiar with it, and manually download binaries (and/or build them).

In either case, I don't see OP's statement to be in line with reality. This is especially the case with PPA where you basically only need to run 'apt-get update && apt-get upgrade' and everything is done.

I was about to ask about that. Would it have been better, in this instance, if the alert system was still at the developers' disposal?

Actually it wouldn't. AFAIK the way that the alert system was implemented was also problematic; there was no sure way to tell how many people have access to the key(s). So for example, if an agency compromised a single developer and took the key we couldn't really know (heck, he might not know himself if they did it secretly while they question him on some false grounds). Additionally, it is an issue of centralization vs. decentralization again which is also why it eventually got thrown out.

But is that enough? There is about 80% of nodes that have'nt done the upgrade.

~70%. Use this: https://bitnodes.earn.com/nodes/ for a sufficient estimate. The thread isn't as serious as it was assuming miners and major economic players have updated, and given that a large portion of the network already did upgrade. I'm certain that the release of 0.17.0 will speed this up as well.

[Ix]

2) Updates can never be automatic for a decentralized system as such. Even adding something like a 'update available' notification system can open up more attack vectors and is (as always) prone to abuse.

I agree with the first part, but as far as 'update available' notifications, is it any worse than relying on GPG verification of binaries in the first place? Update notifications could also automate the GPG verification which few people aside from very serious users probably do. Of course that means relying on the key baked into the software, but it is always possible to compromise something somewhere. Having to read the news to find out there is a critical vulnerability in the software you are using does not seem to be ideal, imo.

[Lauda]

2) Updates can never be automatic for a decentralized system as such. Even adding something like a 'update available' notification system can open up more attack vectors and is (as always) prone to abuse.

I agree with the first part, but as far as 'update available' notifications, is it any worse than relying on GPG verification of binaries in the first place? Update notifications could also automate the GPG verification which few people aside from very serious users probably do. Of course that means relying on the key baked into the software, but it is always possible to compromise something somewhere. Having to read the news to find out there is a critical vulnerability in the software you are using does not seem to be ideal, imo.

This also comes back to the 'control issue' that I believe. The alert key system was able to do exactly that, but it was ultimately removed. I believe that there are no plans to implement something similar at this time.

[Ix]

The alert key posed problems because it was part of the protocol. Dev GPG key verification can be done wholly client side and could even be set to trust only developers X and Y or what have you. Set the sites you want to check for updates, set the keys you need to verify a binary. Probably have some simple protocol that allows for a high priority message to be sent to the user. No one has much control over this situation except the user and who owns what keys are irrelevant as long as they aren't all compromised.