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 ) 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 ; 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> <1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com> <1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com> <4FFB5A7E.7020604@justmoon.de> <4FFB9537.8040909@justmoon.de> <4FFB9707.9020307@gmail.com> Date: Mon, 9 Jul 2012 23:05:44 -0400 Message-ID: From: Gregory Maxwell To: Alan Reiner 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 03:05:51 -0000 On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner 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