1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
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 <shadders.del@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAK5y1FhQLWXtqHfB3HymOkZ-5LdTqdEkX8bM=nOGhFeZrOPwgA@mail.gmail.com>
<1315495242.2795.4.camel@BMThinkPad.lan.bluematt.me>
Date: Fri, 9 Sep 2011 01:25:57 +1000
Message-ID: <CAOPxoMv7EGwgBNuvYpaD_4LtyxUUCvQ2Pe0DCZO4uHoAoMyfnA@mail.gmail.com>
From: Steve Coughlan <shadders.del@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
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: <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 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" <bitcoin-list@bluematt.me> 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
<p>Who knows, it might be the only way we'll ever hear from Satoshi aga=
in.</p>
<div class=3D"gmail_quote">On Sep 9, 2011 1:21 AM, "Matt Corallo"=
<<a href=3D"mailto:bitcoin-list@bluematt.me">bitcoin-list@bluematt.me</=
a>> wrote:<br type=3D"attribution">> On Thu, 2011-09-08 at 07:42 -070=
0, David Perry wrote:<br>
>> There has been some discussion on the new Bitcoin StackExchange si=
te<br>>> lately about the alert protocol. A few have suggested that i=
t might<br>>> carry the potential for abuse (spam/DoS) and others hav=
e argued that<br>
>> it's merely deprecated. In any case, enough have voiced concer=
ns that<br>>> I've forked bitcoin/bitcoin, removed the snippet of=
code from main.cpp<br>>> that makes the questionable call and submit=
ted a pull request. On that<br>
>> pull request it was noted by Gavin Andresen that it merited discus=
sion<br>>> here and some kind of consensus should be reached before a=
cting on<br>>> that pull request. It was also mentioned that he thoug=
ht the feature<br>
>> was still more useful than dangerous and that he would argue again=
st.<br>>> <br>>> <br>>> So I pose the question to you fin=
e fellows: Is the alert system<br>>> valuable, an unnecessary risk or=
merely a snippet of deprecated code?<br>
>> Should it be removed?<br>> <br>> The alert system requires a=
signature verification when it receives an<br>> alert, but so do blocks=
and transactions so it really isn't a DoS target<br>> (remember tha=
t the alert system requires alerts to be signed by a key<br>
> that only gavin and satoshi have).<br>> <br>> The alert system c=
ould prove very, very valuable. In much software it<br>> carries the ri=
sk for abuse or simply seems wrong that the developers can<br>> send a m=
essage to everyone's computer to notify them of something, but<br>
> keep in mind that Bitcoin is financial software. If there is an urgen=
t<br>> problem (like the overflow bug) there must be a way to notify peo=
ple to<br>> upgrade immediately, which is exactly what alerts provide. =
Since alerts<br>
> no longer carry the ability to put Bitcoin into RPC safe-mode, they ar=
e<br>> literally just a message and I see no reason why they should be r=
emoved.<br>> <br>> <br>> -----------------------------------------=
-------------------------------------<br>
> Doing More with Less: The Next Generation Virtual Desktop <br>> Wha=
t are the key obstacles that have prevented many mid-market businesses<br>&=
gt; from deploying virtual desktops? How do next-generation virtual deskt=
ops<br>
> provide companies an easier-to-deploy, easier-to-manage and more affor=
dable<br>> virtual desktop model.<a href=3D"http://www.accelacomm.com/ja=
w/sfnl/114/51426474/">http://www.accelacomm.com/jaw/sfnl/114/51426474/</a><=
br>
> _______________________________________________<br>> Bitcoin-develo=
pment mailing list<br>> <a href=3D"mailto:Bitcoin-development@lists.sour=
ceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>> <a href=
=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https=
://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
--90e6ba6e8b1a6ea11f04ac6fad64--
|
