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

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.

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.

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

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.

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?

Because it is not a priority.

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.

Right, so why hasn't that been implemented?


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!

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

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

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.

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!

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.

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

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

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

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.

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 other justification¹ was that the


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)