Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R1gUT-0005f6-8H for bitcoin-development@lists.sourceforge.net; Thu, 08 Sep 2011 15:26:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.161.174 as permitted sender) client-ip=209.85.161.174; envelope-from=shadders.del@gmail.com; helo=mail-gx0-f174.google.com; Received: from mail-gx0-f174.google.com ([209.85.161.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1R1gUN-0006kA-K1 for bitcoin-development@lists.sourceforge.net; Thu, 08 Sep 2011 15:26:09 +0000 Received: by gxk21 with SMTP id 21so3241gxk.5 for ; Thu, 08 Sep 2011 08:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.154.136 with SMTP id q8mr352937icw.109.1315495557898; Thu, 08 Sep 2011 08:25:57 -0700 (PDT) Received: by 10.231.15.67 with HTTP; Thu, 8 Sep 2011 08:25:57 -0700 (PDT) Received: by 10.231.15.67 with HTTP; Thu, 8 Sep 2011 08:25:57 -0700 (PDT) In-Reply-To: <1315495242.2795.4.camel@BMThinkPad.lan.bluematt.me> References: <1315495242.2795.4.camel@BMThinkPad.lan.bluematt.me> Date: Fri, 9 Sep 2011 01:25:57 +1000 Message-ID: From: Steve Coughlan To: Matt Corallo Content-Type: multipart/alternative; boundary=90e6ba6e8b1a6ea11f04ac6fad64 X-Spam-Score: 1.1 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shadders.del[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: bluematt.me] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1R1gUN-0006kA-K1 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Alert System X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:26:09 -0000 --90e6ba6e8b1a6ea11f04ac6fad64 Content-Type: text/plain; charset=ISO-8859-1 Who knows, it might be the only way we'll ever hear from Satoshi again. On Sep 9, 2011 1:21 AM, "Matt Corallo" wrote: > 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. > > > ------------------------------------------------------------------------------ > 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 --90e6ba6e8b1a6ea11f04ac6fad64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Who knows, it might be the only way we'll ever hear from Satoshi aga= in.

On Sep 9, 2011 1:21 AM, "Matt Corallo"= <bitcoin-list@bluematt.me> wrote:
> On Thu, 2011-09-08 at 07:42 -070= 0, David Perry wrote:
>> There has been some discussion on the new Bitcoin StackExchange si= te
>> lately about the alert protocol. A few have suggested that i= t might
>> carry the potential for abuse (spam/DoS) and others hav= e argued that
>> it's merely deprecated. In any case, enough have voiced concer= ns that
>> I've forked bitcoin/bitcoin, removed the snippet of= code from main.cpp
>> that makes the questionable call and submit= ted a pull request. On that
>> pull request it was noted by Gavin Andresen that it merited discus= sion
>> here and some kind of consensus should be reached before a= cting on
>> that pull request. It was also mentioned that he thoug= ht the feature
>> was still more useful than dangerous and that he would argue again= st.
>>
>>
>> So I pose the question to you fin= e 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 tha= t the alert system requires alerts to be signed by a key
> that only gavin and satoshi have).
>
> The alert system c= ould prove very, very valuable. In much software it
> carries the ri= sk for abuse or simply seems wrong that the developers can
> send a m= essage to everyone's computer to notify them of something, but
> keep in mind that Bitcoin is financial software. If there is an urgen= t
> problem (like the overflow bug) there must be a way to notify peo= ple to
> upgrade immediately, which is exactly what alerts provide. = Since alerts
> no longer carry the ability to put Bitcoin into RPC safe-mode, they ar= e
> literally just a message and I see no reason why they should be r= emoved.
>
>
> -----------------------------------------= -------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> Wha= t are the key obstacles that have prevented many mid-market businesses
&= gt; from deploying virtual desktops? How do next-generation virtual deskt= ops
> provide companies an easier-to-deploy, easier-to-manage and more affor= dable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/<= br> > _______________________________________________
> Bitcoin-develo= pment mailing list
> Bitcoin-development@lists.sourceforge.net
> https= ://lists.sourceforge.net/lists/listinfo/bitcoin-development
--90e6ba6e8b1a6ea11f04ac6fad64--