Alert System
18 messages, 8 to 9 Sep 2011. Started by David Perry.
Luke Dashjr (3), David Perry (2), Steve Shadders (2), Matt Corallo (2), John Smith (2), theymos (2), Pieter Wuille, Mike Hearn, +3 more
There has been some discussion on the new Bitcoin StackExchange<http://bitcoin.stackexchange.com>site lately about the alert protocol. A few have suggested that it might carry the potential for abuse (spam/DoS) and others have argued that it's merely deprecated. In any case, enough have voiced concerns that I've forked bitcoin/bitcoin, removed the snippet of code from main.cpp that makes the questionable call and submitted a pull request<https://github.com/bitcoin/bitcoin/pull/506>. On that pull request it was noted by Gavin Andresen that it merited discussion here and some kind of consensus should be reached before acting on that pull request. It was also mentioned that he thought the feature was still more useful than dangerous and that he would argue against.
So I pose the question to you fine fellows: Is the alert system valuable, an unnecessary risk or merely a snippet of deprecated code? Should it be removed?
Sources: http://bitcoin.stackexchange.com/questions/583/what-is-the-alert-system-in-the-bitcoin-protocol-how-does-it-work/590 http://bitcoin.stackexchange.com/questions/636/is-the-alert-system-still-in-the-main-clients-code-will-it-be-removed/711
I think there's a significant risk to not having it at this stage. There's many reasons why an urgent update may been to rapidly propagated in this stage of the network's lifecycle. Perhaps if there's a perceived threat of abuse the protocol could be altered slightly so it can't carry content. Only a notification of the fact that there is an alert. Then it would be up to individual clients whether they react to it or not. The main clients would probably check a central trusted server for actual alert content. This would give a lot more flexibility in how to deal with the alert. Alert content servers could for example implement a json api to provide alert content with meta data like target client version, priority etc.
I think it should be removed in the future but not for a good while yet.
On 09/09/11 00:42, David Perry wrote:
Quoted text (34 lines)
> There has been some discussion on the new Bitcoin StackExchange > <http://bitcoin.stackexchange.com> site lately about the alert > protocol. A few have suggested that it might carry the potential for > abuse (spam/DoS) and others have argued that it's merely deprecated. > In any case, enough have voiced concerns that I've forked > bitcoin/bitcoin, removed the snippet of code from main.cpp that makes > the questionable call and submitted a pull request > <https://github.com/bitcoin/bitcoin/pull/506>. On that pull request it > was noted by Gavin Andresen that it merited discussion here and some > kind of consensus should be reached before acting on that pull > request. It was also mentioned that he thought the feature was still > more useful than dangerous and that he would argue against. > > So I pose the question to you fine fellows: Is the alert system > valuable, an unnecessary risk or merely a snippet of deprecated code? > Should it be removed? > > Sources: > http://bitcoin.stackexchange.com/questions/583/what-is-the-alert-system-in-the-bitcoin-protocol-how-does-it-work/590 > http://bitcoin.stackexchange.com/questions/636/is-the-alert-system-still-in-the-main-clients-code-will-it-be-removed/711 > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Thu, 2011-09-08 at 07:42 -0700, David Perry wrote:
Quoted text (15 lines)
> There has been some discussion on the new Bitcoin StackExchange site > lately about the alert protocol. A few have suggested that it might > carry the potential for abuse (spam/DoS) and others have argued that > it's merely deprecated. In any case, enough have voiced concerns that > I've forked bitcoin/bitcoin, removed the snippet of code from main.cpp > that makes the questionable call and submitted a pull request. On that > pull request it was noted by Gavin Andresen that it merited discussion > here and some kind of consensus should be reached before acting on > that pull request. It was also mentioned that he thought the feature > was still more useful than dangerous and that he would argue against. > > > So I pose the question to you fine fellows: Is the alert system > valuable, an unnecessary risk or merely a snippet of deprecated code? > Should it be removed?
The alert system requires a signature verification when it receives an alert, but so do blocks and transactions so it really isn't a DoS target (remember that the alert system requires alerts to be signed by a key that only gavin and satoshi have).
The alert system could prove very, very valuable. In much software it carries the risk for abuse or simply seems wrong that the developers can send a message to everyone's computer to notify them of something, but keep in mind that Bitcoin is financial software. If there is an urgent problem (like the overflow bug) there must be a way to notify people to upgrade immediately, which is exactly what alerts provide. Since alerts no longer carry the ability to put Bitcoin into RPC safe-mode, they are literally just a message and I see no reason why they should be removed.
Who knows, it might be the only way we'll ever hear from Satoshi again. On Sep 9, 2011 1:21 AM, "Matt Corallo" <bitcoin-list@bluematt•me> wrote:
Quoted text (33 lines)
> On Thu, 2011-09-08 at 07:42 -0700, David Perry wrote: >> There has been some discussion on the new Bitcoin StackExchange site >> lately about the alert protocol. A few have suggested that it might >> carry the potential for abuse (spam/DoS) and others have argued that >> it's merely deprecated. In any case, enough have voiced concerns that >> I've forked bitcoin/bitcoin, removed the snippet of code from main.cpp >> that makes the questionable call and submitted a pull request. On that >> pull request it was noted by Gavin Andresen that it merited discussion >> here and some kind of consensus should be reached before acting on >> that pull request. It was also mentioned that he thought the feature >> was still more useful than dangerous and that he would argue against. >> >> >> So I pose the question to you fine fellows: Is the alert system >> valuable, an unnecessary risk or merely a snippet of deprecated code? >> Should it be removed? > > The alert system requires a signature verification when it receives an > alert, but so do blocks and transactions so it really isn't a DoS target > (remember that the alert system requires alerts to be signed by a key > that only gavin and satoshi have). > > The alert system could prove very, very valuable. In much software it > carries the risk for abuse or simply seems wrong that the developers can > send a message to everyone's computer to notify them of something, but > keep in mind that Bitcoin is financial software. If there is an urgent > problem (like the overflow bug) there must be a way to notify people to > upgrade immediately, which is exactly what alerts provide. Since alerts > no longer carry the ability to put Bitcoin into RPC safe-mode, they are > literally just a message and I see no reason why they should be removed. > > >
------------------------------------------------------------------------------
Quoted text (4 lines)
> Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more
affordable
Quoted text (5 lines)
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
@Steve re "Who knows, it might be the only way we'll ever hear from Satoshi again."
That brings up a good point... Does anyone aside from Satoshi actually have the ability to send such an alert? Should we at the very least change the alert system to give such privileges to current devs and ensure that that if the missing Mr. Satoshi has had his key compromised we don't see an authoritative-looking alert come up from a malicious source?
On Thu, 2011-09-08 at 09:09 -0700, David Perry wrote:
Quoted text (6 lines)
> @Steve re "Who knows, it might be the only way we'll ever hear from > Satoshi again." > > > That brings up a good point... Does anyone aside from Satoshi actually > have the ability to send such an alert?
Gavin does
Quoted text (4 lines)
> Should we at the very least change the alert system to give such > privileges to current devs and ensure that that if the missing Mr. > Satoshi has had his key compromised we don't see an > authoritative-looking alert come up from a malicious source?
Meh, why make the key-holder send out two alerts for old clients and new clients. I also highly doubt satoshi would let his key get compromised. That said, keep in mind they are literally just messages, they make no functional difference.
On Thu, Sep 08, 2011 at 09:09:12AM -0700, David Perry wrote:
Quoted text (8 lines)
> @Steve re "Who knows, it might be the only way we'll ever hear from Satoshi > again." > > That brings up a good point... Does anyone aside from Satoshi actually have > the ability to send such an alert? Should we at the very least change the > alert system to give such privileges to current devs and ensure that that if > the missing Mr. Satoshi has had his key compromised we don't see an > authoritative-looking alert come up from a malicious source?
Yes, Satoshi transferred the key to Gavin when he "left". I agree we should keep it, btw. There have been suggestions before on this list to use the alert system to ask people to upgrade to recent versions of the client (eg. the disconnect issue 0.3.20-0.3.23 had). I feel there may come a moment when we really need to use it for that purpose.
There is a lot of complaining about this alert system, but I really don't see the problem.
As others have already said, it's just a message. Even if someone managed to compromise the private key, the most they could do is spam graffiti messages or try phishing. There are much worse things that could happen to the network (in which case an alert system could come in very handy). It's just not worth worrying about.
JS
On Thu, Sep 8, 2011 at 4:20 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
Quoted text (35 lines)
> On Thu, Sep 08, 2011 at 09:09:12AM -0700, David Perry wrote: > > @Steve re "Who knows, it might be the only way we'll ever hear from > Satoshi > > again." > > > > That brings up a good point... Does anyone aside from Satoshi actually > have > > the ability to send such an alert? Should we at the very least change the > > alert system to give such privileges to current devs and ensure that that > if > > the missing Mr. Satoshi has had his key compromised we don't see an > > authoritative-looking alert come up from a malicious source? > > Yes, Satoshi transferred the key to Gavin when he "left". I agree we should > keep it, btw. There have been suggestions before on this list to use the > alert system to ask people to upgrade to recent versions of the client (eg. > the disconnect issue 0.3.20-0.3.23 had). I feel there may come a moment > when > we really need to use it for that purpose. > > -- > Pieter > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
Alert system should be upgraded to pop up a dialog box every 30 minutes whilst you're using the software.
Bitcoin is one of the few pieces of software I use that has no concept of automatic updates or even notifications at all. Yet the network badly relies on people upgrading for stability, scalability and to enable new features.
If the alert system goes away, it'd just end up being replaced by polling something over HTTP, which is less decentralized than before. Having zero way to communicate upgrades to end-users is a non-starter for anything serious about mass market penetration.
https://github.com/bitcoin/bitcoin/pull/506 has been closed pending additional commits or a change in consensus.
On Thursday, September 08, 2011 12:51:02 PM Mike Hearn wrote:
Quoted text (9 lines)
> Bitcoin is one of the few pieces of software I use that has no concept of > automatic updates or even notifications at all. Yet the network badly > relies on people upgrading for stability, scalability and to enable new > features. > > If the alert system goes away, it'd just end up being replaced by polling > something over HTTP, which is less decentralized than before. Having zero > way to communicate upgrades to end-users is a non-starter for anything > serious about mass market penetration.
In fact, I think the alert system should relay (note, NOT display) messages *regardless of the key used*, so it isn't yet another "our client gets special status" thing, and can be used for other clients as well.
Be careful though, if you relay everything, it suddenly *does* have DDoS potential...
JS
On Thu, Sep 8, 2011 at 5:15 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (16 lines)
> On Thursday, September 08, 2011 12:51:02 PM Mike Hearn wrote: > > Bitcoin is one of the few pieces of software I use that has no concept of > > automatic updates or even notifications at all. Yet the network badly > > relies on people upgrading for stability, scalability and to enable new > > features. > > > > If the alert system goes away, it'd just end up being replaced by polling > > something over HTTP, which is less decentralized than before. Having zero > > way to communicate upgrades to end-users is a non-starter for anything > > serious about mass market penetration. > > In fact, I think the alert system should relay (note, NOT display) messages > *regardless of the key used*, so it isn't yet another "our client gets > special > status" thing, and can be used for other clients as well. >
On Thursday, September 08, 2011 1:33:15 PM John Smith wrote:
Quoted text (2 lines)
> Be careful though, if you relay everything, it suddenly *does* have DDoS > potential...
Maybe require a proof-of-work then?
Quoted text (7 lines)
> In fact, I think the alert system should relay (note, NOT display) messages > *regardless of the key used*, so it isn't yet another "our client gets > special > status" thing, and can be used for other clients as well. > > > Be careful though, if you relay everything, it suddenly *does* have DDoS
potential...
no more than other messages such as transactions.
Quoted text (1 line)
>Maybe require a proof-of-work then?
kind of defeats the purpose of the alert if it takes a long time to issue one.
I think leave the alert in, but relay alert messages even if they don't use the correct key. This means that if we later decide to add new keys to the alert root trust then older clients will still relay these.
my .02btc
Will
The alert system will be very important if there are ever any critical problems in the network. For example, it is currently Bitcoin's only defense against an attacker with >50% of the computational power, where alerts would be used to tell people to stop accepting transactions.
Displaying a message is pretty harmless. In fact, I don't think the message is prominent enough. The GUI client should not allow people to see received transactions or send new transactions while an alert is in effect (with an opt-out), and there should be an opt-in feature that puts RPC into safe mode in response to an alert.
Alerts are no worse than transactions as a DoS attack vector. They're much safer than typical HTTPS because there are no CAs that can break its security.
(FYI: I also have a copy of the alert key.)
On Thursday, September 08, 2011 3:43:12 PM theymos wrote:
Quoted text (4 lines)
> The alert system will be very important if there are ever any critical > problems in the network. For example, it is currently Bitcoin's only > defense against an attacker with >50% of the computational power, where > alerts would be used to tell people to stop accepting transactions.
I don't seem to recall this ever happening, despite Deepbit having over 50% multiple times now.
On Thursday, September 08, 2011 3:45 PM, "Luke-Jr" <luke@dashjr•org> wrote:
Quoted text (2 lines)
> I don't seem to recall this ever happening, despite Deepbit having over 50% > multiple times now.
An alert would have been issued if they had abused that position.
Resending to mailing list as I replied directly... On Thu, Sep 8, 2011 at 11:03 PM, Christian Decker < decker.christian@gmail•com> wrote:
Quoted text (61 lines)
> > > Will <will@phase•net> wrote: > > >> In fact, I think the alert system should relay (note, NOT display) > >messages > >> *regardless of the key used*, so it isn't yet another "our client > >gets > >> special > >> status" thing, and can be used for other clients as well. > >> > >> > >> Be careful though, if you relay everything, it suddenly *does* have > >DDoS > >potential... > > > >no more than other messages such as transactions. > Only verified and valid trandactions are forwarded which is desired as it > costs the sender a fee if he attempts to spam, messages have no such > penalty. > > > >>Maybe require a proof-of-work then? > > > >kind of defeats the purpose of the alert if it takes a long time to > >issue > >one. > > > >I think leave the alert in, but relay alert messages even if they don't > >use > >the correct key. This means that if we later decide to add new keys to > >the > >alert root trust then older clients will still relay these. > > > >my .02btc > > > >Will > I'm for keeping it in there as well, maybe even extend it with a mechanism > to sign other certificates giving alternative client developers the ability > to issue their own alerts. Think ssl certificates... > > Regards, > Chris > > >------------------------------------------------------------------------------ > >Doing More with Less: The Next Generation Virtual Desktop > >What are the key obstacles that have prevented many mid-market > >businesses > >from deploying virtual desktops? How do next-generation virtual > >desktops > >provide companies an easier-to-deploy, easier-to-manage and more > >affordable > >virtual desktop > >model. > http://www.accelacomm.com/jaw/sfnl/114/51426474/_______________________________________________ > >Bitcoin-development mailing list > >Bitcoin-development@lists•sourceforge•net > >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >