Topic: A replacement Alert System should be considered to promote updates as necessary (Read 1990 times)

Simply because it ensures that anyone who is running software, is made aware of updates/changes/etc.

It would be interesting to know how many 'zombie nodes' are out there - nodes run without any input or oversight that will most likely never upgrade. Probably impossible to determine short of a software survey with user input and some kind of way of measuring historic uptime.


That maybe a worthwhile alternative option/stepping stone.

Why does the alert system have to be in the software itself? Maybe users could be given the option to subscribe via email to receive updates and other information when downloading from https://bitcoin.org/en/download. If you present it well, you can get the email addresses of most of the people downloading the software, then you can just reach them through email whenever you need to inform them about a new version of the software or an issue with the network. Most people do actually check their email often, so you get similar reach as you would with bundling the alert system into the software itself.

As you probably are aware, anyone is welcome to fork Bitcoin Core and re-add the Alert System to it - even the code is out there to re-merge.  Provide the multi-sig keys to whatever group you deem trustworthy, publish that list, and then convince the people who run nodes that the Alert System is a positive for them and have them use your fork.  If indeed it is a good idea, then I suspect that many nodes would update to the Alert System fork since it doesn't involve a blockchain fork or changes to consensus rules.  If people do not believe that it is a useful feature, then they won't use that fork.

As an alternative, you could easily write some very simple software that does this and this alone and convince people who run nodes to run this Alert System software since it would be non-resource intensive.  Or just recommend people who run nodes to monitor IRC, forums, reedit, the bitcoin-dev/disc lists etc.

 

That would be correct, if it was what I said. But subtly, that's not what I said. You should read (and write) more carefully.

You are asking here why are you asking? in Bitcoin you don't ask you suggest, if you are asking with a hope of some particular individuals consider your request then you already determined your stand here, you speak as if you are speaking with a central authority with power to change things but not even developers could do what you asking and even if they could do it then it will be up to users to run that version with alert activated on.
Stop talking to them like they are in charge, I believe that's what they are trying to tell you that there shouldn't be a central source of news and updates.

That's a distinction without a difference. You're saying people can ignore updated software, people can ignore notifications as well.

No.

Users can choose to use new versions of the software, if at all. But they cannot choose whether or not to receive alert messages.


Current situation is a good compromise; you're wrong, the alert system still exists, but it's determined by the software, and has a narrower range of events for which alerts are sent.

The behaviour you're seeking could be added programmatically (i.e. without requiring human input), you could write the code and submit it as a pull request for review.

But this level of trust is already existent with the development of the reference client?

The trusted authority is the group "Bitcoin Core developers" in general. It doesn't matter that there are multiple people in that group who would have to sign off on an alert, they are a trusted authority as they are part of the group "Bitcoin Core developers". Because those developers are part of the same group, they, as an entity, may decide to publish an alert for something which users may not want. Users have to trust that the group as a whole does not partake in any malicious behavior.

But this is my point. This depends entirely upon what message is displayed, and how it is displayed. There are good ways of doing notification, and bad ways.
What you've described above is not what I have said in my posts on this topic. I agree I don't want a notification "commanding urgent and immediate action". But I do still think notifications have their place.



I don't understand what you mean when you refer to a singular "trusted authority". A multisignature system could be setup where you have a 5-of-10, or even a 20-of-30 (or any you consider appropriate), where a set of developers are able to issue notification. The notification multisignature system would be built into the client-release, and should be similar in working to the current development consensus building. In such a system a large number of qualified individuals would form an agreement, directly related to the work that they were carrying out.

If you're referring to the actual notification being the "trusted authority", again, I think that this is based on a very narrow assumption that the notification will be written and presented in a certain way. There are many different ways to write and present notifications.




Please have the courtesy to actually read some previous posts on this topic before putting in a low effort comment like that.

A well designed notification system does not necessarily promote centralisation.

Promotes Centralization - NACK

No it doesn't, in fact a decenteralized system cannot change like that. If bitcoin can be forced into "mandatory mass upgrades" then it has failed.

Moreover, well constructed changes in consensus rules are detected and responded to by existing software:

(And not just at the change, but in advance too!)



I apologize for offending, but you appear to be wading in somewhat uninformed and telling other people what they should do. This is very insulting.  I don't mean to offend, but with your approach you are going to get a blunt response.

Perhaps you didn't intend to, but a world where we depend on trusted parties with special secret keys that have special powers is that kind of world.

And none are official, people use all of them and many more.  There are singular methods of communication that are highly controlled but communication between people is not.

It does not, because a message displayed on your screen commanding urgent and immediate action does not provide a timeframe for public review and communication to take place.

It depends on a trusted authority, the that the authority is a (perhaps informal) corporation rather than a natural person doesn't change the fact that such a system has a fixed center. Not only should users not want to depend on one, prudent parties don't want to be one because of the generation of completely uncompensated risk. (It becomes attractive to compromise or even kidnap key holders in order to generate false notices; no one pays us to take on risks like that so we want.  The kind of people who wouldn't care about that are the kind of people who on no account should you ever trust with it...)


You will have more luck with proposals if you first demonstrate empathy and a high degree of understanding. I don't feel that you are doing that here. In particular, the claims that consensus systems require sudden/unexpected changes or that we're currently not able to have users detect consensus rule changes -- when we already have mechanisms for this which work.

Only talking about clients here.


Yes, people do upgrade, but bitcoin software is a special case as consensus rule changes require mass spontaneous upgrades - which doesn't happen with bitcoin currently, and I'd argue, without a direct means of communication to users - can never happen. That is where I am coming from in my above statement.

Without direct communication to your users, how can you accomplish a timely effective update?


I don't really appreciate the tone here, that's not warranted.
Also, I didn't imply a centralised world, I'm simply referencing one as a common implementation of an alert system - specifically mentioning such an example as something I _don't_ want.


Yes, that was implied in my statement. Only new users (or updating users) would be compromised, however, that caveat doesn't negate my point. It is still a point of trust.

To add to that, there are many other points of trust, such as the communication channels suggested in the BIP discussion and wiki page linked in my original post. Forums, reddit, mailing lists are all centralised forms of communication to some degree. All of those suggested alternatives to an alert/notification system require a level of trust. They are not trustless.


Yes, this justification applies equally to a client alert/notification system.


Multisignature is better described as semi-decentralised.

It is impossible to have a communication medium that is fully decentralised, it's also not practical, or even warranted.

This would be my preliminary proposal for a "best practice" notification system:

• Client based - not network based. Each client would be required to implement their own notification system if not yet implemented
• Multi-sig authoring of notifications. Perhaps by majority of devs
• Ability to permanently disable each notification by user
• Multiple "back out" opportunities for users informing them that they are not required to update (when appropriate)
• Links to open/decentralised discussion channels where the update can be reviewed by peers

Benefits:

* Faster implementation of security improvements
* Faster implementation of consensus rule changes/updates
* Greater likelihood of consensus rule changes/updates
* Faster and more effective communication to users

Downsides:

* Semi-centralisation of update information distribution (in effect no greater than forums, or mailing lists)
* Minuscule risk of notification system being compromised (in reality risk insignificant as would required greater than 50% of devs compromised)

Hey you want an alert system for Bitcoin Core client or the whole network? why don't you propose it for users to decide if they want it? or we could make it optional but available for users. with alert being implemented you are assuming every user is at their GUI watching the screen to see if an alert going to pop up any time now, if there is a critical issue then users will never know until it effects them which by that time they're already alerted.

It sounds like to me that you're making assumptions which are simply not true, then fixating on particular solutions.

People do upgrade, this is a fact and we've seen it quite clearly in practice.  If you want software to nag users when it's really old, it could do that independent of there being any alert system.


"with access to" -- instantly you begin by just _presuming_ a centralized hierarchical world with privileged parties that have power over others.

No, only _new_ users that downloaded it when it was compromised; not everyone already out there.

Most users do not, a few do. If the few that do find problems, they can sound alarms; protecting others (see the prior point).

Multisignature is still trusted and centralized.

Hmmm. If I understand you correctly here, when you say "ongoing and realtime trust requirement" you're specifically referring to an alert/notification system, and not any other part of the software, correct?

So the concern is that if you or any other developer with access to an alert system is compromised, that ongoing trust is also compromised?

I guess my response would be, doesn't that concern also apply to users simply downloading the software? i.e. if the download is compromised, users are compromised. So users currently have a high level of trust that the downloads they obtain are genuine, original, and without security issues (this argument applies to almost everything, there is always a baseline level of trust involved).

You could counter that by saying that users can check the source code, but the reality is apart from some very select people, users aren't reviewing source code, so they have a level of trust, either in the developers, or in their peers who are able to review the code. You could have simpler methods of verification that users can do, such as MD5 hashes which compare with historical MD5 hashes so that you know you can roll back to a previous secure version even if the current download sources are compromised, but again, this is generally beyond the average user.

I guess what I'm saying is, I don't see a great deal of difference between existing system which do have a trust component, and an idealised alert/notification system?

Keep in mind I'm not talking about the old alert system, I'm talking about an ideal alert/notification system, specifically created with the above concerns in mind.

It feels to me like the very concept of an alert system isn't even up for consideration, which I think is a grave mistake.

Without some kind of carefully crafted notification, there will always be users who never ever update. It feels like stagnation is built into this system and it will never be overcome.

An idealised alert/notification system could have multiple failsafes inbuilt such as multi-sig security to prevent malicious developers or compromised developers exerting control.

Kinda matters when you're presuming to tell other people what to do.


Because this requires the source to be honest about XXXXX.  In other words, it requires trust.  We are philosophically opposed to building systems which have an ongoing and realtime trust requirement both out of concern for the security of our users but also as a factor in our own personal safety.

I see what you're saying, but I'm still not convinced and am going to remain in disagreement. (That's okay, can't agree on everything.)

My perspective is that you're painting yourselves into a corner where updates will not be realistically feasible. People simply won't update in such a system. Stagnation seems to be an inevitable consequence.

I also feel like the concerns could be addressed with some lateral thinking. If the concerns are:

* Users update at their own pace
* Users have security considerations with updates
* Users disagree with changes

Why not have an informative window prior to installation of the update? Explaining these very things, with something like a quick executive summary:


To add to that, why not have a system where the alert can be dismissed, i.e. "Alert: New version blah blah, click here for info" and have a button "never show again".

Seems like those two simple things would solve the concerns?

The Bitcoin Core developers want users to update at their own pace whenever they feel comfortable updating. This is because new versions may contain consensus changes that users may not agree with, possible security considerations that users are not comfortable with, etc. By using an alert system to inform people about new versions, we would be pressuring users to update and we do not want to do that as that violates the principle of letting users upgrade whenever they feel comfortable with the changes.

Yep, money tends to inspire a conservative* instinct in all that hold it, commensurately more conservative as the value of the money increases.

That's difficult to align with something as inherently progressive as a radical and developing new tech such as cryptocurrency, and so making careful choices about how/where conservatism and progression can be applied to make a given cryptocurrency both as stable and as agile as possible is what cryptocurrency devs are tasked with. Bitcoin continues to lead on that basis.


* note that this does not mean political conservatism as a package, simply the desire to conserve the exchange value of an asset whose only inherent value is that of a medium of exchange, which is a delicate task. "Conserve" is a real word, that means something wider than its political connotations.