you want an alert system for Bitcoin Core client or the whole network?
Only talking about clients here.
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.
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?
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 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.
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.
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.
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).
Yes, this justification applies equally to a client alert/notification system.
prevent malicious developers or compromised developers exerting control.
Multisignature is still trusted and centralized.
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)
