A replacement Alert System should be considered to promote updates as necessary

[doctor-s]

I've been reading over a few bits of history (see sources below), and the removal of the alert system has bothered me quite a bit. It was stated here⁴ that:

The Alert system has also lost its usefulness. It is no longer necessary to use it to inform users about problematic network events as users can easily get their information from any major Bitcoin news outlet.

The other justification¹ was that the

Alert Key (was) Compromised

This is related to the fact that there was a single key for the alert system, which was handed out to a number of core devs, and over the years people left the project. Thus it was thought that this was a risk (in that people could send alerts without vetting) that might affect users.

I wanted to talk about this because although I agree with the latter (I don't believe that you can leave the key for an alert system in the hands of so many people), I disagree with the former. The alert system had not lost it's usefulness at all.

The justification was that communication could be done to the community through:

• forums
• reddit
• slack
• github
• an opt in mailing list

IMO this is an incredibly short sighted point of view, and one that is now biting us in the butt. One of the major bottlenecks to getting BIPs through has been the difficulty in communicating to clients and getting clients updated to prevent problems.

An alert system is incredibly useful in the event of a necessary HF to implement proposed BIPs. This has been a HUGE issue in the community and it could have been avoided had an alert system of some kind been kept in place/added.

An alert system completely solves the issue of users forgoing critical updates to their clients, which allows for faster progress in development.

I think this is something that needs to be discussed and pushed forward perhaps in the future. Some may think it is too late to do something now, but while the best time for the alert system was yesterday, the second best time is today.

Example of the old alert system:


Sources:

1. Alert System - Bitcoin Wiki -(https://en.bitcoin.it/wiki/Alert_system)
2. Github alert system removal 1 - (https://github.com/bitcoin/bitcoin/pull/6260)
3. Github alert system removal 2 - (https://github.com/bitcoin/bitcoin/pull/7692)
4. Bitcoin.org announcement of removal - (https://bitcoin.org/en/alert/2016-11-01-alert-retirement)

[1713509897]

1713509897

[1713509897]

1713509897

[1713509897]

1713509897

[1713509897]

1713509897

[1713509897]

1713509897

[aleksej996]

Another reason might be just centralization.

The compromise of the key is kind of the consequence of the centralization. It isn't the best idea to get someone to be the main source of information in a decentralized system. Adding Alert key would get people to abandon their sources of news to a degree and rely on the Alert system, which would cause centralization.

Even in some case if Alerts aren't used, it could be dangerous, since people might think that there is nothing to report while an important discussion might be talking place.

[Coding Enthusiast]

I couldn't agree more. In fact I raised this question before the Hard Fork since it was the most relevant time to "warn" about it. But since I am usually not good in putting things into words, I gave up

I also don't see why the alert system is a point of centralization, or why they talk about risk of keys being compromised. A new alert system could have been put in place of the old like this:
The alert text tells the user that something is going on. Check where you downloaded this application for more information from the developers of the same app, and where would that be? Github, bitcoin.org, mailing list. But you at least told the users to go check it out and they won't be in the blind.
I don't see any way to compromise this either!

As for centralization, if you call that alert system centralization then you should call the fact that certain people are coding for bitcoin and @laanwj is the only person merging PRs (or possibly others) a point of centralization too! Because same people are putting up warnings on bitcoin.org, bitcointalk, reddit, mailing list,...

... BUT that is just what I think, and apparently nobody else agrees

[achow101]

There were actually multiple problems with the alert system that caused its removal, not just that the key was compromised or that users can get their information from other sources. The alert system was a major source of centralization; those who held the alert keys could send an alert to everyone in the network. This is undesirable for a decentralized system. The general agreement was that the alert system should not be networkwide, rather it should be software specific and up to the developers of their respective software to alert their users of ongoing events.

Furthermore, the alert system actually has a number of DoS vulnerabilities (i.e. node takedown bugs) that can't really be fixed without completely overhauling the system.

And the alert key being compromised is a significant concern. No one knows who actually holds the alert key and anyone who holds it could give it to anyone else if they so wished. Because of the DoS vulnerabilities in the Alert system, that is a major problem because if one person were malicious, they could take down the entire network by broadcasting one message to every node.

I also don't see why the alert system is a point of centralization, or why they talk about risk of keys being compromised. A new alert system could have been put in place of the old like this:
The alert text tells the user that something is going on. Check where you downloaded this application for more information from the developers of the same app, and where would that be? Github, bitcoin.org, mailing list. But you at least told the users to go check it out and they won't be in the blind.
I don't see any way to compromise this either!

For a while, there was significant concern that Gavin Andresen was going to publish an alert telling everyone to upgrade to Bitcoin XT. The alert text can have whatever the alert author wants in it, so he could have written a long statement telling users something that wasn't "go check where you downloaded this application for more info" but rather "Emergency, you must download software from this site NOW".

@laanwj is the only person merging PRs

No he isn't. Stop spreading that FUD. Jonasschnelli, MarcoFalke, and sipa have commit access as well and frequently merge PRs.

[Coding Enthusiast]

The alert text can have whatever the alert author wants in it, so he could have written a long statement telling users something that wasn't "go check where you downloaded this application for more info" but rather "Emergency, you must download software from this site NOW".

I was talking about a "replacement", a new alert system if you will that sends alerts with codes not texts. A set of predefined codes can be set, each meaning something different. I don't know, something like Code_1 = Hard Fork is going on, or Code_2 = A critical Bug were found Check trusted sources for more info.

@laanwj is the only person merging PRs....(or possibly others)

No he isn't. Stop spreading that FUD. Jonasschnelli, MarcoFalke, and sipa have commit access as well and frequently merge PRs.

I just said that name because that was the one off the top of my mind. Not sure where the FUD comes in!

My point is if you think X & Y & Z having alert keys of possibly a modified/improved alert system like what i said above (which in practice alerts people using their code of critical issues in their code) makes it centralized, then you should also think X & Y & Z having commit access to bitcoin core GitHub repo also makes it centralized!

[Carlton Banks]

As for centralization, if you call that alert system centralization then you should call the fact that certain people are coding for bitcoin and @laanwj is the only person merging PRs (or possibly others) a point of centralization too!

Sometimes decentralised systems are appropriate. Sometimes they aren't. Because sometimes they work. And sometimes they don't.


It's just too much of a risk to go through the Gavin Andresen situation again, it's just a waste of time that can be avoided.


Also, none of this reasoning is convincing. If soft fork BIPs just needed an alert sent on the client to get activated, it would have been very easy to get BIP142 over the signalling threshold (and this leaves the mystery of why every other soft fork was never activated that way).

[Coding Enthusiast]

I do understand the possible risks/vulnerabilities and the reason for removal of that alert system, but I still feel a void.

[doctor-s]

The general agreement was that the alert system should not be networkwide, rather it should be software specific and up to the developers of their respective software to alert their users of ongoing events.

Right, so why hasn't that been implemented?

I do understand the possible risks/vulnerabilities and the reason for removal of that alert system, but I still feel a void.

Yes, this was the point of my post. I understand the reasons for removing the previous alert system, but why wouldn't you have alert systems in each software client?

The # 1 complaint is that it's very hard to get people to update their clients. If you have a large, very noticeable alert system you avoid this problem almost entirely!

I'd argue that out of all bitcoin development going on, this is probably the most important. Because if you're going to get any other updates/changes through, you need to actually inform people of them in the first place!

[achow101]

Right, so why hasn't that been implemented?

Because it is not a priority.

I'd argue that out of all bitcoin development going on, this is probably the most important. Because if you're going to get any other updates/changes through, you need to actually inform people of them in the first place!

No. An alert system should only ever be used to inform users of security problems or forking events. It should never be used to inform users of updates, software improvements, new versions, etc. that are not related to the security of a user's coins. Any sort of intentional fork should never be announced over any alert system.

[doctor-s]

No. An alert system should only ever be used to inform users of security problems or forking events. It should never be used to inform users of updates, software improvements, new versions, etc. that are not related to the security of a user's coins. Any sort of intentional fork should never be announced over any alert system.

1. Why? You've said this as if it's self-evident, but it isn't. What's wrong with alerts/notifications for updates? I guess you could argue "alert fatigue" would lead to people ignoring it, but then ok, if I go with this...
2. So keep the alert system for hard fork changes? There's a huge wishlist of things that are never going to be implemented at the current rate because nobody wants to do a hardfork - for the very reason that you can't get users to upgrade their software. Why isn't an alert system seen as a solution to this problem?

[achow101]

1. Why? You've said this as if it's self-evident, but it isn't. What's wrong with alerts/notifications for updates? I guess you could argue "alert fatigue" would lead to people ignoring it, but then ok, if I go with this...

The general principle of how Bitcoin Core operates with updates is that users can and should update at their own pace. The developers should never pressure users to update to a new version of the software. By using such an alert system to inform people of new software versions, we would be pressuring people to update more so than not informing them at all through the client.

2. So keep the alert system for hard fork changes? There's a huge wishlist of things that are never going to be implemented at the current rate because nobody wants to do a hardfork - for the very reason that you can't get users to upgrade their software. Why isn't an alert system seen as a solution to this problem?

No, the alert system is for security events and network breaking events like unintentional hard forks. Intentional planned hard forks should also not be announced via the alert system as that would be pressuring users to upgrade to a new version which we want to avoid.

[doctor-s]

that would be pressuring users to upgrade to a new version which we want to avoid.

I don't see why that's a problem? If you've created and released better software, why wouldn't you want your users to update?

[Kogs]

What about adding somewhere a window in the Bitcoin Core GUI what just renders a specific page from the bitcoin.org site?
It would be an easy way to bring news to people. If someone is interested in the news, they open this window, others who don't care about it, just don't open it.

Independent of this, I'm wondering how the alert system worked with demonized full nodes?
Were the alerts only shown in the logs or was there any other fancy mechanism to notify the user who runs the bitcoind in background?

I think, most full nodes in the network are just running in the background without gui (are there any statistics about this?). So how was the old alert system designed to reach them?

Taking me as example, I run a full node without GUI, and I never check the logs as long as my block height don't differ from the networks block height.

[aleksej996]

that would be pressuring users to upgrade to a new version which we want to avoid.

I don't see why that's a problem? If you've created and released better software, why wouldn't you want your users to update?

Core devs have a little bit of a different idea then you of what Bitcoin is. The whole premise of it is that Bitcoin is a stable and secure network.
There are plenty of coins with a lot of new features on a network and client level and Bitcoin will never be able to compete with that.

Instead, as the oldest cryptocurrency Bitcoin has been developing as the most stable and secure, where even small changes, like scaling issue, is very rigorously discussed. You can see that it took a lot of drama to implement a simple change and Core devs didn't even want a hard fork if they could go around it. That is why segwit is a soft fork and as a soft work, old clients don't need to upgrade.

Core celebrates the fact that it is the oldest coin and it respects that through not adding much change over time and instead focusing on improving and rigorously testing the already established features. Core wants Bitcoin to be cryptocurrency first and all the other features are completely unnecessary to it.
There are many of cryptocurrencies out there now, but Bitcoin is most developed, most adopted, most secure and most stable. That is what Bitcoin is in the eyes of Core team and a big user base behind it.

[Carlton Banks]

Instead, as the oldest cryptocurrency Bitcoin has been developing as the most stable and secure, where even small changes, like scaling issue, is very rigorously discussed.

[snip]

Core celebrates the fact that it is the oldest coin and it respects that through not adding much change over time and instead focusing on improving and rigorously testing the already established features.

[snip]

There are many of cryptocurrencies out there now, but Bitcoin is most developed, most adopted, most secure and most stable.

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.

[achow101]

I don't see why that's a problem? If you've created and released better software, why wouldn't you want your users to update?

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.

[doctor-s]

I don't see why that's a problem? If you've created and released better software, why wouldn't you want your users to update?

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.

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:

Code:

This update contains XXXXX, some users may not wish to update, **you do not need to update**. 
If you do not agree you are welcome to continue using the previous version. 
Please click cancel and continue using your current client

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?

[gmaxwell]

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.)

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

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

Code:

This update contains XXXXX, some users may not wish to update, **you do not need to update**. 
If you do not agree you are welcome to continue using the previous version. 
Please click cancel and continue using your current client

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.

[doctor-s]

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.

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.

[gmaxwell]

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.

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.

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

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

I guess my response would be, doesn't that concern also apply to users simply downloading the software?

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

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,

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

prevent malicious developers or compromised developers exerting control.

Multisignature is still trusted and centralized.