📅 Original date posted:2012-07-10
📝 Original message:> 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.
True, it's those compromises that people should base their decision on.
To make that easier was the motivation for me to suggest feature
matrices in the first place.
Right now if I read Electrum's description, it doesn't say anything
about the tradeoffs with a lightweight client like the slightly weaker
privacy guarantees. At best I could deduce that from the fact that
unlike Bitcoin-Qt it doesn't explicitly list privacy as an advantage.
So applying the same "MyBitcoin test" to the current Bitcoin Clients
page and if you want to be fair, we'd have to assume that if it was
indeed included it would also just be a short pitch listing only pros
and no cons. So it would say something like: "MyBitcoin starts instantly
and is really easy to use and great for beginners." etc.
Obviously if you compare a bad matrix to good short descriptions and
vice versa you'll get the conclusion you're trying to get.
I think Alan had the best idea - let's have the Clients page as it is
and have it link to the wiki for those who want a more detailed
comparison. On the wiki page we can then have explanations of the basic
client types, separate matrices for features and for security/privacy
and whatever else might be useful to know when choosing a client. Then
users who don't really care aren't bothered by "too much information"
and users who do can easily click through and find out about the
different tradeoffs.
On 7/10/2012 5:05 AM, Gregory Maxwell wrote:
> On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi at 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"— 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
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Stefan Thomas [ARCHIVE] /
npub1f8…ap20e
2023-06-07 10:21:49
in reply to nevent1q…y2vx
Author Public Key
npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20ePublished at
2023-06-07 10:21:49Event JSON
{
"id": "c08d08ad5c5b9ed11d349bcc095f5a185038e880afd7ee40eff7d4a400f8b3ec",
"pubkey": "49f07bd32c0108a2903a0fa59f904ed312e0ea427d3269eb5fa910eb4a9e22c4",
"created_at": 1686133309,
"kind": 1,
"tags": [
[
"e",
"cc6bba8fda1c3a64a0e3f616ccacf637aeea7329d9f2665d6c8e9d6a789d86de",
"",
"root"
],
[
"e",
"e8da6e1e71c324a71a591912a5c34f9ce40bf5923d1d7d4ca833e650e3f5e7f2",
"",
"reply"
],
[
"p",
"30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722"
]
],
"content": "📅 Original date posted:2012-07-10\n📝 Original message:\u003e I wouldn't expect any really important features which don't have\n\u003e complicated compromises attached to them to be omitted from all\n\u003e clients for all that long.\n\nTrue, it's those compromises that people should base their decision on.\nTo make that easier was the motivation for me to suggest feature\nmatrices in the first place.\n\nRight now if I read Electrum's description, it doesn't say anything\nabout the tradeoffs with a lightweight client like the slightly weaker\nprivacy guarantees. At best I could deduce that from the fact that\nunlike Bitcoin-Qt it doesn't explicitly list privacy as an advantage.\n\nSo applying the same \"MyBitcoin test\" to the current Bitcoin Clients\npage and if you want to be fair, we'd have to assume that if it was\nindeed included it would also just be a short pitch listing only pros\nand no cons. So it would say something like: \"MyBitcoin starts instantly\nand is really easy to use and great for beginners.\" etc.\n\nObviously if you compare a bad matrix to good short descriptions and\nvice versa you'll get the conclusion you're trying to get.\n\nI think Alan had the best idea - let's have the Clients page as it is\nand have it link to the wiki for those who want a more detailed\ncomparison. On the wiki page we can then have explanations of the basic\nclient types, separate matrices for features and for security/privacy\nand whatever else might be useful to know when choosing a client. Then\nusers who don't really care aren't bothered by \"too much information\"\nand users who do can easily click through and find out about the\ndifferent tradeoffs.\n\nOn 7/10/2012 5:05 AM, Gregory Maxwell wrote:\n\u003e On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\u003e What a feature matrix is good at though is it allows you to very quickly\n\u003e\u003e find the specific feature or general criteria you're looking for without\n\u003e\u003e reading through all of the text. So it might be a useful addition maybe\n\u003e\u003e not on Bitcoin.org, but certainly on the wiki.\n\u003e I'm generally not a fan of feature matrixes, they encourage \"checkbox\n\u003e decision making\"— which is seldom very good for the decider, though\n\u003e it's much loved by the marketing department that puts together the\n\u003e matrix. But just becase something is loved by marketing departments\n\u003e for its ability to set the agenda in variously biased ways doesn't\n\u003e mean its a great thing to emulate.\n\u003e\n\u003e Take the matrix Luke linked to for example[1]. Now imagine that we\n\u003e tunnel MyBitcoin from a year ago and drop it into that table. It\n\u003e would have every light green, except 'encryption' (which wouldn't have\n\u003e been green for bitcoin-qt then either). It would basically be the\n\u003e dominant option by the matrix comparison, and this is without any\n\u003e lobbying to get MyBitcoin specific features (like their shopping chart\n\u003e interface) added, not to mention the \"_vanishes with everyone's\n\u003e money_\" feature.\n\u003e\n\u003e I don't think I'm being unreasonable to say that if you could drop in\n\u003e something that retrospectively cost people a lot into your decision\n\u003e matrix and it comes out on top you're doing something wrong.\n\u003e\n\u003e In tables like this significant differences like \"a remote hacker can\n\u003e rob you\" get reduced to equal comparison with \"chrome spoiler\", and\n\u003e it further biases development motivations towards features that make\n\u003e nice bullets (even if they're seldom used) vs important infrastructure\n\u003e which may invisibly improve usage every day or keeps the network\n\u003e secure and worth having. \"Of course I want the fastest startup! Why\n\u003e would I choose anything else?\" \"What do you mean all my bitcoin is\n\u003e gone because the four remaining full nodes were taken over and reorged\n\u003e it all?\"\n\u003e\n\u003e I wouldn't expect any really important features which don't have\n\u003e complicated compromises attached to them to be omitted from all\n\u003e clients for all that long.\n\u003e\n\u003e Basically matrixes make bad decision making fast, and by making it\n\u003e fast it's more attractive than careful decision making that always\n\u003e takes time. The text is nice because it contextualizes the complete\n\u003e feature set and helps you understand why different clients exist, what\n\u003e problems they attempt to solve, and what compromises they make. ...\n\u003e without making the unrealistic demand of the user they they know how\n\u003e to fairly weigh the value of technical and sometimes subtle issues.\n\u003e\n\u003e\n\u003e [1] https://en.bitcoin.it/wiki/Clients\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and \n\u003e threat landscape has changed and how IT managers can respond. Discussions \n\u003e will include endpoint security, mobile security and the latest in malware \n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "88933642025f8011ab6287d4d8456080b87f19b7696ab7bc12881bfdc33fef5db9e5d9ba32a7f50e2d82c24fc9ac4d1f95925b591a0f950babf8556a00815c68"
}