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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SoIJW-0007GS-IF
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 18:04:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=etotheipi@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoIJV-0000Pt-BN
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 18:04:02 +0000
Received: by weyr6 with SMTP id r6so5303014wey.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 11:03:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.93.68 with SMTP id cs4mr31342980wib.14.1341857035208; Mon,
09 Jul 2012 11:03:55 -0700 (PDT)
Received: by 10.194.8.39 with HTTP; Mon, 9 Jul 2012 11:03:55 -0700 (PDT)
In-Reply-To: <CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<CAAS2fgRd0gqrxXs4Le6nydYBaG7EO=T7FrtX6QZpg3aJtAxSvg@mail.gmail.com>
<1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
Date: Mon, 9 Jul 2012 14:03:55 -0400
Message-ID: <CALf2ePwKcRWmaw=S=dFs8QTSg98obyYPoP2U21H5UL30KDBxmA@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043892bdec466c04c4696fb8
X-Spam-Score: -0.6 (/)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1SoIJV-0000Pt-BN
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Random order for clients page
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: Mon, 09 Jul 2012 18:04:02 -0000
--f46d043892bdec466c04c4696fb8
Content-Type: text/plain; charset=ISO-8859-1
I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that "clients" page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
link of where to find more information (i.e. the wiki). I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.
We either have to have a "czar" who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call. Or we just move it to another page that is less
strictly controlled and where these things matter less. Trying to gain
consensus among an amalgamation of developers all with competing priorities
and "products" is a terrible way to try to agree on stuff.
-Alan
On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> > JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> JS randomization doesn't imply needing JS to view the page. It implies
> needing JS to see it in random order. You could also combine it with
> the server-side randomization if you care about non-js being non
> random, though I don't think it matters.
>
> As others have pointed out I don't generally think the randomization
> is good in principle, but if its done it should at least achieve its
> goals.
>
> > Only you have a problem with this page. I don't see why Bitcoin-Qt needs
> to be first either when it dominates the front page. It is perfectly fine
> as it is.
>
> I'll let other people speak for themselves, but I did consult others
> before reverting your last batch of changes.
>
> More generally, we have pull requests in order to get some peer review
> of changes. Everyone should use them except for changes which are
> urgent or trivially safe. (Presumably everyone with access knows how
> to tell if their changes are likely to be risky or controversial)
>
> > You are not a developer of any alternative clients, and this is a
> webpage for Bitcoin clients. I have made a change to remove a source of
> disputes, and make the process more fair and equal. Your suggestion to
> remove the clients page is your bias towards thinking that there should be
> only one Bitcoin client that everyone uses (the one which you contribute
> towards).
>
> I'm strongly supportive diversity in the Bitcoin network, and some alt
> client developers can speak to the positive prodding I've given them
> towards becoming more complete software. If I've said anything that
> suggests otherwise I'd love to be pointed to it in order to clarify my
> position.
>
> Unfortunately none of the primary alternatives are yet complete, the
> network would be non-function if it consisted entirely of multibit or
> electrum nodes (and as you've noted armory uses a local reference
> client as its 'server'). The distinction between multiple kinds of
> clients in terms of security and network health are subtle and can be
> difficult to explain even to technical users and so until something
> changes there the reference client needs to be the option we lead
> with. People should us it unless their use-case doesn't match. When it
> does they'll know it and they'll be looking. We don't need to make one
> of those recommendations a primary option.
>
> I like the proposals of moving this stuff to the Wiki as the wiki
> already contains tons of questionable (and sometimes contradictory)
> advice and so there is less expectation that placement there implies
> any vetting.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d043892bdec466c04c4696fb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I generally agree with Greg. =A0 I don't see anything he's said or =
done as anti-alt-client.<div><br></div><div>As an alt-client developer, I&#=
39;m happy to see my client on the main page, but I'm also happy if tha=
t "clients" page is simply an acknowledgement that there's mo=
re to the Bitcoin world than just the Bitcoin-Qt client, and a link of wher=
e to find more information (i.e. the wiki). =A0I would still <i>prefer</i>=
=A0to have the page the way it is, because I think alt clients should be mo=
re accessible and word will spread better where it is now -- but I also rec=
ognize the inherent difficulty of gaining any kind of consensus of how it s=
hould be organized, what goes on the list, etc, and no matter how you do it=
, someone will complain about it being unfair or not right.</div>
<div><br></div><div>We either have to have a "czar" who is truste=
d to make responsible decisions, and complaints of being unfair or recommen=
dations for improvements can go through that person, but ultimately it is t=
hat person who makes the call. =A0Or we just move it to another page that i=
s less strictly controlled and where these things matter less. =A0Trying to=
gain consensus among an amalgamation of developers all with competing prio=
rities and "products" is a terrible way to try to agree on stuff.=
</div>
<div><br></div><div>-Alan<br><div><div><br></div><div><br><div><br><br><div=
class=3D"gmail_quote">On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <spa=
n dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">g=
maxwell@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Jul 9, 2012 at 12:=
09 PM, Amir Taaki <<a href=3D"mailto:zgenjix@yahoo.com">zgenjix@yahoo.co=
m</a>> wrote:<br>
> JS randomisation is bad. People shouldn't need JS to view a webpag=
e.<br>
<br>
</div>JS randomization doesn't imply needing JS to view the page. It im=
plies<br>
needing JS to see it in random order. =A0You could also combine it with<br>
the server-side randomization if you care about non-js being non<br>
random, though I don't think it matters.<br>
<br>
As others have pointed out I don't generally think the randomization<br=
>
is good in principle, but if its done it should at least achieve its<br>
goals.<br>
<div class=3D"im"><br>
> Only you have a problem with this page. I don't see why Bitcoin-Qt=
needs to be first either when it dominates the front page. It is perfectly=
fine as it is.<br>
<br>
</div>I'll let other people speak for themselves, but I did consult oth=
ers<br>
before reverting your last batch of changes.<br>
<br>
More generally, we have pull requests in order to get some peer review<br>
of changes. =A0Everyone should use them except for changes which are<br>
urgent or trivially safe. =A0(Presumably everyone with access knows how<br>
to tell if their changes are likely to be risky or controversial)<br>
<div class=3D"im"><br>
> You are not a developer of any alternative clients, and this is a webp=
age for Bitcoin clients. I have made a change to remove a source of dispute=
s, and make the process more fair and equal. Your suggestion to remove the =
clients page is your bias towards thinking that there should be only one Bi=
tcoin client that everyone uses (the one which you contribute towards).<br>
<br>
</div>I'm strongly supportive diversity in the Bitcoin network, and som=
e alt<br>
client developers can speak to the positive prodding I've given them<br=
>
towards becoming more complete software. If I've said anything that<br>
suggests otherwise I'd love to be pointed to it in order to clarify my<=
br>
position.<br>
<br>
Unfortunately none of the primary alternatives are yet complete, the<br>
network would be non-function if it consisted entirely of multibit or<br>
electrum nodes (and as you've noted armory uses a local reference<br>
client as its 'server'). =A0The distinction between multiple kinds =
of<br>
clients in terms of security and network health are subtle and can be<br>
difficult to explain even to technical users and so until something<br>
changes there the reference client needs to be the option we lead<br>
with. People should us it unless their use-case doesn't match. When it<=
br>
does they'll know it and they'll be looking. We don't need to m=
ake one<br>
of those recommendations a primary option.<br>
<br>
I like the proposals of moving this stuff to the Wiki as the wiki<br>
already contains tons of questionable (and sometimes contradictory)<br>
advice and so there is less expectation that placement there implies<br>
any vetting.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div></div></div>
--f46d043892bdec466c04c4696fb8--
|
