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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SoQlr-0004Jg-RM
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Jul 2012 03:05:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=gmaxwell@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoQlq-00061P-Pk
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Jul 2012 03:05:51 +0000
Received: by pbbrq2 with SMTP id rq2so19185262pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 20:05:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.219.162 with SMTP id pp2mr39101034pbc.85.1341889544740;
Mon, 09 Jul 2012 20:05:44 -0700 (PDT)
Received: by 10.68.59.6 with HTTP; Mon, 9 Jul 2012 20:05:44 -0700 (PDT)
In-Reply-To: <4FFB9707.9020307@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>
<1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<CANEZrP1vwDubXrY3eoq4P4SAN=GK06iVaVx4pMWZKmBwQc9awg@mail.gmail.com>
<4FFB5A7E.7020604@justmoon.de>
<CANEZrP3Y3nvRwiPw66bDhp01JnE-zVurw5MnxPzR-bi5H8h4Aw@mail.gmail.com>
<4FFB9537.8040909@justmoon.de> <4FFB9707.9020307@gmail.com>
Date: Mon, 9 Jul 2012 23:05:44 -0400
Message-ID: <CAAS2fgT10nf=8TJxYrT4WBNdYUiSU7qQNDTjjbTSuMktn2QVpw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SoQlq-00061P-Pk
Cc: 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: Tue, 10 Jul 2012 03:05:51 -0000
On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
I'm generally not a fan of feature matrixes, they encourage "checkbox
decision making"=E2=80=94 which is seldom very good for the decider, though
it's much loved by the marketing department that puts together the
matrix. But just becase something is loved by marketing departments
for its ability to set the agenda in variously biased ways doesn't
mean its a great thing to emulate.
Take the matrix Luke linked to for example[1]. Now imagine that we
tunnel MyBitcoin from a year ago and drop it into that table. It
would have every light green, except 'encryption' (which wouldn't have
been green for bitcoin-qt then either). It would basically be the
dominant option by the matrix comparison, and this is without any
lobbying to get MyBitcoin specific features (like their shopping chart
interface) added, not to mention the "_vanishes with everyone's
money_" feature.
I don't think I'm being unreasonable to say that if you could drop in
something that retrospectively cost people a lot into your decision
matrix and it comes out on top you're doing something wrong.
In tables like this significant differences like "a remote hacker can
rob you" get reduced to equal comparison with "chrome spoiler", and
it further biases development motivations towards features that make
nice bullets (even if they're seldom used) vs important infrastructure
which may invisibly improve usage every day or keeps the network
secure and worth having. "Of course I want the fastest startup! Why
would I choose anything else?" "What do you mean all my bitcoin is
gone because the four remaining full nodes were taken over and reorged
it all?"
I wouldn't expect any really important features which don't have
complicated compromises attached to them to be omitted from all
clients for all that long.
Basically matrixes make bad decision making fast, and by making it
fast it's more attractive than careful decision making that always
takes time. The text is nice because it contextualizes the complete
feature set and helps you understand why different clients exist, what
problems they attempt to solve, and what compromises they make. ...
without making the unrealistic demand of the user they they know how
to fairly weigh the value of technical and sometimes subtle issues.
[1] https://en.bitcoin.it/wiki/Clients
|
