diff options
| author | Will <will@phase.net> | 2011-09-08 20:25:22 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-09-08 20:29:52 +0000 |
| commit | b01f82e3a1b290b961e8789d72cae4544c7e6c17 (patch) | |
| tree | 24f91322e226f655e29a801b0be0f02c681810b9 | |
| parent | 0406b489ae0c6a2593f579fcb7f8954d0681ae9c (diff) | |
| download | pi-bitcoindev-b01f82e3a1b290b961e8789d72cae4544c7e6c17.tar.gz pi-bitcoindev-b01f82e3a1b290b961e8789d72cae4544c7e6c17.zip | |
Re: [Bitcoin-development] Alert System
| -rw-r--r-- | 42/e429377bab80fdb75bf762a1c302a8a8e46b89 | 102 |
1 files changed, 102 insertions, 0 deletions
diff --git a/42/e429377bab80fdb75bf762a1c302a8a8e46b89 b/42/e429377bab80fdb75bf762a1c302a8a8e46b89 new file mode 100644 index 000000000..adf74067e --- /dev/null +++ b/42/e429377bab80fdb75bf762a1c302a8a8e46b89 @@ -0,0 +1,102 @@ +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't yet another "our client = +gets special<br> +status" thing, and can be used for other clients as well.<br> +<div><div></div><div class=3D"h5"><br></div></div></blockquote><div><br>>= +; 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>>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'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-- + + |