Bitcoin Forum

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:
https://i.imgur.com/Oq2r5Ka.png

Sources:

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

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 couldn't agree more. In fact I raised this question before the Hard Fork (https://bitcointalk.org/index.php?topic=2044836.0) 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 :P

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 :P

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 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! :P

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!

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 do understand the possible risks/vulnerabilities and the reason for removal of that alert system, but I still feel a void.

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!

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.

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?

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.

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?

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.

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.

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.

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:


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?

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.

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.

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.

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.

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)

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

https://people.xiph.org/~greg/temp/warning_in_gui.png

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.

Promotes Centralization - NACK

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.

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 level of trust is already existent with the development of the reference client?

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.

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

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 would be correct, if it was what I said. But subtly, that's not what I said. You should read (and write) more carefully.

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.

 :)

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.

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.