Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <will@phase.net>) id 1R1lEO-0005UH-Mv
	for bitcoin-development@lists.sourceforge.net;
	Thu, 08 Sep 2011 20:29:52 +0000
X-ACL-Warn: 
Received: from mail-gy0-f175.google.com ([209.85.160.175])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1R1lEO-00010k-1C
	for bitcoin-development@lists.sourceforge.net;
	Thu, 08 Sep 2011 20:29:52 +0000
Received: by gyg8 with SMTP id 8so1031704gyg.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 08 Sep 2011 13:29:46 -0700 (PDT)
Received: by 10.42.19.132 with SMTP id c4mr474429icb.4.1315509942212; Thu, 08
	Sep 2011 12:25:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.199.12 with HTTP; Thu, 8 Sep 2011 12:25:22 -0700 (PDT)
In-Reply-To: <201109081315.12643.luke@dashjr.org>
References: <CAK5y1FhQLWXtqHfB3HymOkZ-5LdTqdEkX8bM=nOGhFeZrOPwgA@mail.gmail.com>
	<CAJNQ0suvvAC+TBu5Cbt+Q2=aycMnVHRXXGccEdytSZOj10w5JA@mail.gmail.com>
	<CANEZrP2sbLc-ATpf7Uu1S6UQfhd2LPPoHRJmvjZuzH2CUS-TqQ@mail.gmail.com>
	<201109081315.12643.luke@dashjr.org>
From: Will <will@phase.net>
Date: Thu, 8 Sep 2011 20:25:22 +0100
Message-ID: <CAHQs=o5xSLa7+eMRT+eskdMw=jVNwxj9gGYyjqtwZyxXbnRxcg@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=20cf30427198cdd69404ac7306d0
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1R1lEO-00010k-1C
Cc: bitcoin-development@lists.sourceforge.net, David Perry <enmaku@gmail.com>
Subject: Re: [Bitcoin-development] Alert System
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 20:29:52 -0000

--20cf30427198cdd69404ac7306d0
Content-Type: text/plain; charset=ISO-8859-1

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

>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

--20cf30427198cdd69404ac7306d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In fact, I think=
 the alert system should relay (note, NOT display) messages<br>
*regardless of the key used*, so it isn&#39;t yet another &quot;our client =
gets special<br>
status&quot; thing, and can be used for other clients as well.<br>
<div><div></div><div class=3D"h5"><br></div></div></blockquote><div><br>&gt=
; Be careful though, if you relay everything, it suddenly *does* have DDoS =
potential...<br><br>no more than other messages such as transactions. <br>

<br>&gt;Maybe require a proof-of-work then?<br><br>kind of defeats the purp=
ose of the alert if it takes a long time to issue one.<br><br>I think leave=
 the alert in, but relay alert messages even if they don&#39;t use the corr=
ect key.=A0 This means that if we later decide to add new keys to the alert=
 root trust then older clients will still relay these.<br>

<br>my .02btc<br><br>Will<br></div></div>

--20cf30427198cdd69404ac7306d0--