* Re: [Bitcoin-development] Random order for clients page @ 2012-07-09 18:54 Jim 2012-07-09 18:57 ` Gregory Maxwell 0 siblings, 1 reply; 27+ messages in thread From: Jim @ 2012-07-09 18:54 UTC (permalink / raw) To: bitcoin-development I think we are all so familiar with Bitcoin that we forget how daunting and confusing it all is to new users. The clients page does a good job in explaining that there are various pieces of software that they (the new user) can use with their bitcoins. It also helps with the question "Who can I trust ?" By having the clients on a link from the "mothership" of bitcoin.org it gives credence to all of the alt clients. This last point is a good reason to only include open source clients IMHO. RE: The position randomisation - I have to admit I was secretly pleased with the original layout, as MultiBit just happened to have the "eye candy" position of "top and centre". It is only fair to have them switch around. -- http://multibit.org Money, reinvented ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:54 [Bitcoin-development] Random order for clients page Jim @ 2012-07-09 18:57 ` Gregory Maxwell 2012-07-09 19:14 ` Alan Reiner 0 siblings, 1 reply; 27+ messages in thread From: Gregory Maxwell @ 2012-07-09 18:57 UTC (permalink / raw) To: Jim; +Cc: bitcoin-development On Mon, Jul 9, 2012 at 2:54 PM, Jim <jim618@fastmail•co.uk> wrote: > RE: The position randomisation - I have to admit I was secretly pleased > with the original layout, as MultiBit just happened to have the "eye > candy" position of "top and centre". It is only fair to have them > switch around. This ordering wasn't accidental. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:57 ` Gregory Maxwell @ 2012-07-09 19:14 ` Alan Reiner 2012-07-09 20:13 ` Gary Rowe 0 siblings, 1 reply; 27+ messages in thread From: Alan Reiner @ 2012-07-09 19:14 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development, Jim [-- Attachment #1: Type: text/plain, Size: 2558 bytes --] I was originaly for the idea of randomization. Because it is the most "fair", but "fair" is a relative term. It's fair for client developers who argue over whose client should be first, and whose is better for various purposes. But it's not fair for users, to have an inconsistent page, that sometimes recommends less-developed solutions, or doesn't show what's best *for the users in the community*. I think the premise of having a page that is "fair for developers" is its downfall. Once we agree things have to be fair, we must agree on what fair means, and then we must accept 30 new recently-started projects that barely squeak by the requirements for being on the page, despite having substantial issues/bugs. The premise of being fair is the downfall here. This *has* to be a subjective list. Someone who is trusted to understand what is good for users, and who also has familiarity with the programs, should be the one to decide. People can try to provide input, and make them aware of stuff they didn't know. But it should be *that person's*decision, and if it's not "fair" in your world, too bad. At least we won't spend the next 3 years arguing on the mailing list about how to compare programs that are all great in many different dimensions, and failing in the others. If it's going to go on the main page, give someone the responsibility to come up with "what's best for the users of Bitcoin.org", however they decide to interpret it, and save our breath arguing over more important things. -Alan On Mon, Jul 9, 2012 at 2:57 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > On Mon, Jul 9, 2012 at 2:54 PM, Jim <jim618@fastmail•co.uk> wrote: > > RE: The position randomisation - I have to admit I was secretly pleased > > with the original layout, as MultiBit just happened to have the "eye > > candy" position of "top and centre". It is only fair to have them > > switch around. > > This ordering wasn't accidental. > > > ------------------------------------------------------------------------------ > 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 > [-- Attachment #2: Type: text/html, Size: 3525 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 19:14 ` Alan Reiner @ 2012-07-09 20:13 ` Gary Rowe 0 siblings, 0 replies; 27+ messages in thread From: Gary Rowe @ 2012-07-09 20:13 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4004 bytes --] Although I can only speak for my involvement with MultiBit, the idea of a randomised client page seems wrong to me, for the reasons given by Alan earlier. Equally, in order to further the idea that Bitcoin is more than the reference client, it is appropriate that other clients are acknowledged and promoted. Bitcoin.org has by far the most traffic and by directing people to other clients that may be more suitable to their needs the user experience is improved considerably. After all, not everyone wants a 2.5Gb+ download before starting out on their Bitcoin adventure. If the reference client was the best of all possible worlds then there would be no need for the alternative clients. On 9 July 2012 20:14, Alan Reiner <etotheipi@gmail•com> wrote: > I was originaly for the idea of randomization. Because it is the most > "fair", but "fair" is a relative term. It's fair for client developers who > argue over whose client should be first, and whose is better for various > purposes. But it's not fair for users, to have an inconsistent page, that > sometimes recommends less-developed solutions, or doesn't show what's best > *for the users in the community*. > > I think the premise of having a page that is "fair for developers" is its > downfall. Once we agree things have to be fair, we must agree on what fair > means, and then we must accept 30 new recently-started projects that barely > squeak by the requirements for being on the page, despite having > substantial issues/bugs. The premise of being fair is the downfall here. > > This *has* to be a subjective list. Someone who is trusted to > understand what is good for users, and who also has familiarity with the > programs, should be the one to decide. People can try to provide input, > and make them aware of stuff they didn't know. But it should be *that > person's* decision, and if it's not "fair" in your world, too bad. At > least we won't spend the next 3 years arguing on the mailing list about how > to compare programs that are all great in many different dimensions, and > failing in the others. > > If it's going to go on the main page, give someone the responsibility to > come up with "what's best for the users of Bitcoin.org", however they > decide to interpret it, and save our breath arguing over more important > things. > > -Alan > > > > On Mon, Jul 9, 2012 at 2:57 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote: > >> On Mon, Jul 9, 2012 at 2:54 PM, Jim <jim618@fastmail•co.uk> wrote: >> > RE: The position randomisation - I have to admit I was secretly pleased >> > with the original layout, as MultiBit just happened to have the "eye >> > candy" position of "top and centre". It is only fair to have them >> > switch around. >> >> This ordering wasn't accidental. >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > > > ------------------------------------------------------------------------------ > 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 > > [-- Attachment #2: Type: text/html, Size: 5614 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bitcoin-development] Random order for clients page @ 2012-07-09 15:54 Amir Taaki 2012-07-09 16:04 ` Gregory Maxwell 2012-07-09 17:33 ` Nils Schneider 0 siblings, 2 replies; 27+ messages in thread From: Amir Taaki @ 2012-07-09 15:54 UTC (permalink / raw) To: bitcoin-development Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 15:54 Amir Taaki @ 2012-07-09 16:04 ` Gregory Maxwell 2012-07-09 16:09 ` Amir Taaki 2012-07-09 20:44 ` Jeff Garzik 2012-07-09 17:33 ` Nils Schneider 1 sibling, 2 replies; 27+ messages in thread From: Gregory Maxwell @ 2012-07-09 16:04 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote: > Took me a while, but finally got it working. > Entries on the clients page are randomly ordered when the page is generated. > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing it. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:04 ` Gregory Maxwell @ 2012-07-09 16:09 ` Amir Taaki 2012-07-09 16:39 ` Stefan Thomas 2012-07-09 17:46 ` Gregory Maxwell 2012-07-09 20:44 ` Jeff Garzik 1 sibling, 2 replies; 27+ messages in thread From: Amir Taaki @ 2012-07-09 16:09 UTC (permalink / raw) To: bitcoin-development JS randomisation is bad. People shouldn't need JS to view a webpage. 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. 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). If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website. Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now. ----- Original Message ----- From: Gregory Maxwell <gmaxwell@gmail•com> To: Amir Taaki <zgenjix@yahoo•com> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Monday, July 9, 2012 5:04 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote: > Took me a while, but finally got it working. > Entries on the clients page are randomly ordered when the page is generated. > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing it. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:09 ` Amir Taaki @ 2012-07-09 16:39 ` Stefan Thomas 2012-07-09 16:55 ` Harald Schilly 2012-07-09 17:46 ` Gregory Maxwell 1 sibling, 1 reply; 27+ messages in thread From: Stefan Thomas @ 2012-07-09 16:39 UTC (permalink / raw) To: bitcoin-development > You are not a developer of any alternative clients I am and I'm going to have to agree with Greg. Information about clients is bound to be transient and controversial. My relatively naive suggestion would be to move it to the Wiki. If it can handle the controversies involved with the Trade page, it should easily be able to handle the controversies involved with a Clients page like this one. A link to that page could be added under Bitcoin Wiki on Bitcoin.org. On the subject of randomization, I think that's a bad idea. Randomness does not equal fairness and more importantly it does not serve the users, which should be the overriding concern. As a user I don't want to be recommended a random client but the most sensible choice. As alternative client implementors we should not be overly concerned about Bitcoin.org recommending the wrong client, truly good clients will benefit from word-of-mouth and eventually rise to the top. If you want a "fair" ordering, then I'd order by number of downloads for downloadable clients and Alexa rank for any hosted / online services if it were decided that such should be listed at all. On 7/9/2012 6:09 PM, Amir Taaki wrote: > JS randomisation is bad. People shouldn't need JS to view a webpage. > > 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. > > 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). > > If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website. > > Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now. > > > > ----- Original Message ----- > From: Gregory Maxwell <gmaxwell@gmail•com> > To: Amir Taaki <zgenjix@yahoo•com> > Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> > Sent: Monday, July 9, 2012 5:04 PM > Subject: Re: [Bitcoin-development] Random order for clients page > > On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote: >> Took me a while, but finally got it working. >> Entries on the clients page are randomly ordered when the page is generated. >> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 >> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. > If you had authored this as a pull request rather than making the > change unilaterally I would have recommended leaving it so the > reference client was always first. I also would have suggested that it > use JS randomization instead of jekyll in order to get more even > coverage, though I think thats a more minor point. > > Some people were concerned when this page was created that it would > just be a source of useless disputes. I think its becoming clear that > this is the case. I think the cost of dealing with this page is > starting to exceed the benefit it provides and we should probably > consider removing it. > > > ------------------------------------------------------------------------------ > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:39 ` Stefan Thomas @ 2012-07-09 16:55 ` Harald Schilly 2012-07-09 17:21 ` Luke-Jr 0 siblings, 1 reply; 27+ messages in thread From: Harald Schilly @ 2012-07-09 16:55 UTC (permalink / raw) To: Stefan Thomas; +Cc: bitcoin-development On Mon, Jul 9, 2012 at 6:39 PM, Stefan Thomas <moon@justmoon•de> wrote: > As a user I don't want to > be recommended a random client but the most sensible choice. > ... wiki page ... I think this is indeed a controversal topic. I just want to add the remark, that it would make sense to have the wiki page *and* this more "official" page. I would envision this official page as some kind of "stamp of approval" which includes some sensible criteria, e.g. it works for many users, the development hasn't stopped some time ago (bitrot), code review, the author(s) is/are known to the community, private keys aren't accessible by the webservice, etc. The ordering should be by alphabet, in a vertical list with a short unbiased description. Harald ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:55 ` Harald Schilly @ 2012-07-09 17:21 ` Luke-Jr 0 siblings, 0 replies; 27+ messages in thread From: Luke-Jr @ 2012-07-09 17:21 UTC (permalink / raw) To: bitcoin-development; +Cc: Harald Schilly FWIW, all this argumenting is why my original suggestion for a Clients list focussed on objective information in alphabetical order. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:09 ` Amir Taaki 2012-07-09 16:39 ` Stefan Thomas @ 2012-07-09 17:46 ` Gregory Maxwell 2012-07-09 18:03 ` Alan Reiner 2012-07-09 18:18 ` Amir Taaki 1 sibling, 2 replies; 27+ messages in thread From: Gregory Maxwell @ 2012-07-09 17:46 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 17:46 ` Gregory Maxwell @ 2012-07-09 18:03 ` Alan Reiner 2012-07-09 18:29 ` thomasV1 2012-07-09 18:18 ` Amir Taaki 1 sibling, 1 reply; 27+ messages in thread From: Alan Reiner @ 2012-07-09 18:03 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4650 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 5730 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:03 ` Alan Reiner @ 2012-07-09 18:29 ` thomasV1 0 siblings, 0 replies; 27+ messages in thread From: thomasV1 @ 2012-07-09 18:29 UTC (permalink / raw) To: bitcoin-development I agree with Alan. I too am happy to see my client listed on bitcoin.org, and I don't mind Bitcoin-Qt being listed first. I have no problem with a "czar" approach if it can solve conflicts. I believe that it is useful to keep the 'clients' page on bitcoin.org, because it contributes to clarifying the difference between the Bitcoin client and Bitcoin as a protocol/network/ecosystem. It shows that Bitcoin is much more than its original implementation. It is a sign of health. Thomas -------- Original-Nachricht -------- > Datum: Mon, 9 Jul 2012 14:03:55 -0400 > Von: Alan Reiner <etotheipi@gmail•com> > An: Gregory Maxwell <gmaxwell@gmail•com> > CC: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> > Betreff: Re: [Bitcoin-development] Random order for clients page > 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 > > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 17:46 ` Gregory Maxwell 2012-07-09 18:03 ` Alan Reiner @ 2012-07-09 18:18 ` Amir Taaki 2012-07-09 18:30 ` Mike Hearn 2012-07-09 18:48 ` Gregory Maxwell 1 sibling, 2 replies; 27+ messages in thread From: Amir Taaki @ 2012-07-09 18:18 UTC (permalink / raw) To: bitcoin-development This page really does matter to alternative clients. If you measure the click through statistics, then they are a significant portion of the traffic. By removing this page, you are directly stunting Bitcoin's growth. The only thing that's changed between now and this morning is: - Addition of Bitcoin Wallet for Android - Randomisation of entries I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by: - laanwj - gavin - sipa - jgarzik - BlueMatt - Diapolo - luke-jr - you - jim from multibit - gary rowe - ThomasV - me - etotheipi - Andreas Schildbach - justmoon - Mike Hearn You're proposing to remove the page. You know, and I know and I know that you know that nobody visits the Wiki. Your proposal is not "move to Wiki" really but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is against the stated goals of the rest of your team members (gavin, sipa, jgarzik). Have you tried the new clients? I've tried all 4, and they are all well written. Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has. MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys. Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is extremely well thought out in how the user navigates through the software. The Bitcoin network could function perfectly fine with Electrum nodes and miners. You would still have miners and we wouldn't have the problem now with huge blocks because miners would be economically incentivised to keep blocks small. But that's another discussion. Technically speaking, the randomisation is fine now. It achieves its intended effect, as the page is regenerated daily. This does not need to be a source of arguing. I see no problem with having this page be a neutral overview of the main clients (as we all agreed together in the beginning): - Source must be public, and users must be able to run from source. - Description should be non-spammy and neutral sounding. Cover the negative aspects. Randomisation of the order simply makes that fairer. Alphabetical is not a good option (as others have suggested) because it can be gamed. There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community. ----- Original Message ----- From: Gregory Maxwell <gmaxwell@gmail•com> To: Amir Taaki <zgenjix@yahoo•com> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Monday, July 9, 2012 6:46 PM Subject: Re: [Bitcoin-development] Random order for clients page 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:18 ` Amir Taaki @ 2012-07-09 18:30 ` Mike Hearn 2012-07-09 22:26 ` Stefan Thomas 2012-07-09 18:48 ` Gregory Maxwell 1 sibling, 1 reply; 27+ messages in thread From: Mike Hearn @ 2012-07-09 18:30 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development It's easy to say, this page is controversial, so let's get rid of it. However that starts the project down the road of being dominated by our internal politics rather than what actually makes sense from the end users perspective. That route spells doom for any product. You can always tell when a UI or product is the result of internal politics, whether it be the difficulty of plug-n-play hardware on Linux (no driver api) to how Microsoft is incapable of producing anything that isn't built on Windows. Gmail labs is another example of this. It makes sense that if I go to bitcoin.org, I am educated about the system and what is available for it. It doesn't make any sense to have some stuff on the main site and other stuff on a wiki (which may get randomly vandalized and looks less professional), based on how "controversial" some developers find it. FWIW I am dead set against anyone randomly changing the website without a pull request and such changes should be reverted and resubmitted through the proper channels. I don't perceive much value in randomization or trying to make this page "fair". If anything, we need to pick somebody (one person) who has a strong focus on regular people and their needs, then just make them the sole committer to the website. That way disputes can be resolved by them making a decision, instead of ridiculous edit wars. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:30 ` Mike Hearn @ 2012-07-09 22:26 ` Stefan Thomas 2012-07-09 22:37 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Stefan Thomas @ 2012-07-09 22:26 UTC (permalink / raw) To: bitcoin-development > However that starts the project down the road of being dominated by > our internal politics rather than what actually makes sense from the > end users perspective. I strongly agree, but this is *why* I suggested moving it to the wiki. I recently had to choose an XMPP client and I looked on xmpp.org - after a frustrating experience with their listing [1], I went to Wikipedia who have an decent feature-based matrix [2]. (There may be better examples, but I'm using this one, because this actually did happen.) This is just anecdotal, but there are some reasons why wikis tend to do a better for this kind of thing is because they are: - more up-to-date (anyone can update them) - more in touch with users: -> Users can edit the page and add a column to a feature matrix for example). -> The editing discussions include users. I guarantee there are more Bitcoin end users with a wiki account than a Github account. - immediately recognizable as a wiki (thanks to Mediawiki/Wikipedia.) As such many users will correctly treat and interpret the information presented as community-generated and fallible. So they are more user-oriented in the sense that they will be influenced by a diverse set of backgrounds and views vs. a Github based page which will be dominated by developers. If you want to see "the result of internal politics", the current client page is a good example. We couldn't agree on the columns for a feature matrix, so now we just have walls of text. Some of the options that are de-facto the most popular with users like BlockChain.info or just using your MtGox account are not mentioned at all. When analyzing client security, Greg discussed counterparty risks but ignored other risk factors like default backup behavior and the usability of security features. But even if I grant you that those clients' overall risk profile is worse than Bitcoin-Qt's, maybe I'm happy to take that risk in exchange for less setup/maintenance effort. Based on our support requests at WeUseCoins I know that there are tons of users with < 1 BTC in their wallets. If my hourly wage is 20$ and I have 20$ in my Bitcoin wallet then spending one hour per month downloading/updating/figuring-out the client is equivalent to a total loss. The list is obviously designed by open-source developers and that's fine, it's bitcoin.org, arguably we *should* try to push users in a specific direction, arguably we *should* err on the side of caution in order to not be caught recommending a hosted wallet that gets hacked. But if user orientation is supposed to be the focus, then the wiki will both allow us (because it's less "official") and force us (because users will have a say) to include even clients we personally wouldn't use. :) [1] http://xmpp.org/xmpp-software/clients/ [2] http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features On 7/9/2012 8:30 PM, Mike Hearn wrote: > It's easy to say, this page is controversial, so let's get rid of it. > > However that starts the project down the road of being dominated by > our internal politics rather than what actually makes sense from the > end users perspective. That route spells doom for any product. You can > always tell when a UI or product is the result of internal politics, > whether it be the difficulty of plug-n-play hardware on Linux (no > driver api) to how Microsoft is incapable of producing anything that > isn't built on Windows. Gmail labs is another example of this. > > It makes sense that if I go to bitcoin.org, I am educated about the > system and what is available for it. It doesn't make any sense to have > some stuff on the main site and other stuff on a wiki (which may get > randomly vandalized and looks less professional), based on how > "controversial" some developers find it. > > FWIW I am dead set against anyone randomly changing the website > without a pull request and such changes should be reverted and > resubmitted through the proper channels. I don't perceive much value > in randomization or trying to make this page "fair". If anything, we > need to pick somebody (one person) who has a strong focus on regular > people and their needs, then just make them the sole committer to the > website. That way disputes can be resolved by them making a decision, > instead of ridiculous edit wars. > > ------------------------------------------------------------------------------ > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 22:26 ` Stefan Thomas @ 2012-07-09 22:37 ` Mike Hearn 2012-07-10 2:36 ` Stefan Thomas 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2012-07-09 22:37 UTC (permalink / raw) To: Stefan Thomas; +Cc: bitcoin-development > I strongly agree, but this is *why* I suggested moving it to the wiki. I > recently had to choose an XMPP client and I looked on xmpp.org - after a > frustrating experience with their listing [1] Probably because their listing is even more useless than any of the proposals that were presented here. Thank goodness it didn't end up like that. Their table doesn't even attempt to list features or differentiating aspects of each client. I think the XMPP guys have pretty much given up on directly marketing the system to end users. > - more up-to-date (anyone can update them) Fortunately reasonable clients don't appear/disappear/change that often. > - more in touch with users: I think by "users" you mean, geeks who understand wiki syntax. Because that's what it'll end up trending towards. I don't believe a wiki would reflect the needs of your average person. It's still better to have these arguments here and try to find a user-focussed consensus than hope one will converge from a wiki. > If you want to see "the result of > internal politics", the current client page is a good example. We > couldn't agree on the columns for a feature matrix, so now we just have > walls of text. Inability to agree on columns isn't why the page looks like that. I know because I'm the one who argued for the current design. It looks like that because feature matrices aren't especially helpful for newbies to make a decision, especially when the "features" in question were often things like how they handled the block chain or which protocol standards they support, ie, things only of interest to developers. It's much easier to communicate the differences to people with a short piece of text, and maybe if there is no obvious way to explain why you'd want to use a given client, that's a good sign it's not worth listing there. Otherwise you end up like xmpp.org. > Some of the options that are de-facto the most popular > with users like BlockChain.info or just using your MtGox account are not > mentioned at all. It's true that bitcoin.org needs to be conservative. That said, I'd like there to be sections for them too, actually. I agree that risk isn't purely about how it's implemented and that whilst we might like to push particular ideologies around protocols or code licensing, that isn't especially relevant to end users who have different priorities. Track record counts for a lot as well. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 22:37 ` Mike Hearn @ 2012-07-10 2:36 ` Stefan Thomas 2012-07-10 2:44 ` Alan Reiner 0 siblings, 1 reply; 27+ messages in thread From: Stefan Thomas @ 2012-07-10 2:36 UTC (permalink / raw) To: bitcoin-development > I think by "users" you mean, geeks who understand wiki syntax. The point is to expand the circle of contributors. I'm pretty sure there are more people who can edit a wiki than people who know HTML and how to create a git pull request. :) > Inability to agree on columns isn't why the page looks like that. My apologies, I vaguely remembered Luke's original proposal and that it got rejected, but you're correct, the reason wasn't a debate on the columns but that people didn't like the feature matrix at all. I didn't really mean to argue on the details of what the page should look like, but just to briefly respond to Mike's point: > It looks like that because feature matrices aren't especially helpful > for newbies to make a decision, especially when the "features" in > question were often things like how they handled the block chain or > which protocol standards they support, ie, things only of interest to > developers. A well-designed feature matrix can quite useful and user-friendly. http://www.apple.com/ipod/compare-ipod-models/ Prose is better to get a sense of the philosophy and basic idea of a client. If it was between having only a feature matrix or only prose, I'd probably go for the prose as well. 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. On 7/10/2012 12:37 AM, Mike Hearn wrote: >> I strongly agree, but this is *why* I suggested moving it to the wiki. I >> recently had to choose an XMPP client and I looked on xmpp.org - after a >> frustrating experience with their listing [1] > Probably because their listing is even more useless than any of the > proposals that were presented here. Thank goodness it didn't end up > like that. Their table doesn't even attempt to list features or > differentiating aspects of each client. > > I think the XMPP guys have pretty much given up on directly marketing > the system to end users. > >> - more up-to-date (anyone can update them) > Fortunately reasonable clients don't appear/disappear/change that often. > >> - more in touch with users: > I think by "users" you mean, geeks who understand wiki syntax. Because > that's what it'll end up trending towards. I don't believe a wiki > would reflect the needs of your average person. It's still better to > have these arguments here and try to find a user-focussed consensus > than hope one will converge from a wiki. > >> If you want to see "the result of >> internal politics", the current client page is a good example. We >> couldn't agree on the columns for a feature matrix, so now we just have >> walls of text. > Inability to agree on columns isn't why the page looks like that. I > know because I'm the one who argued for the current design. > > It looks like that because feature matrices aren't especially helpful > for newbies to make a decision, especially when the "features" in > question were often things like how they handled the block chain or > which protocol standards they support, ie, things only of interest to > developers. > > It's much easier to communicate the differences to people with a short > piece of text, and maybe if there is no obvious way to explain why > you'd want to use a given client, that's a good sign it's not worth > listing there. Otherwise you end up like xmpp.org. > >> Some of the options that are de-facto the most popular >> with users like BlockChain.info or just using your MtGox account are not >> mentioned at all. > It's true that bitcoin.org needs to be conservative. That said, I'd > like there to be sections for them too, actually. I agree that risk > isn't purely about how it's implemented and that whilst we might like > to push particular ideologies around protocols or code licensing, that > isn't especially relevant to end users who have different priorities. > Track record counts for a lot as well. > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-10 2:36 ` Stefan Thomas @ 2012-07-10 2:44 ` Alan Reiner 2012-07-10 3:05 ` Gregory Maxwell 0 siblings, 1 reply; 27+ messages in thread From: Alan Reiner @ 2012-07-10 2:44 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1339 bytes --] On 07/09/2012 10:36 PM, Stefan Thomas wrote: >> It looks like that because feature matrices aren't especially helpful >> for newbies to make a decision, especially when the "features" in >> question were often things like how they handled the block chain or >> which protocol standards they support, ie, things only of interest to >> developers. > A well-designed feature matrix can quite useful and user-friendly. > > http://www.apple.com/ipod/compare-ipod-models/ > > Prose is better to get a sense of the philosophy and basic idea of a > client. If it was between having only a feature matrix or only prose, > I'd probably go for the prose as well. > > 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. > If we're keeping the clients page, I would really like to see the feature matrix linked from that page. It shouldn't be on that main clients page (for the reasons already stated), but Stefan makes a point that /it is really useful for many users./ Add "Compare features of the various different clients here: <link>" and users who will benefit will most definitely click on it. I think that's win-win. [-- Attachment #2: Type: text/html, Size: 1869 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-10 2:44 ` Alan Reiner @ 2012-07-10 3:05 ` Gregory Maxwell 2012-07-10 7:12 ` Wladimir 2012-07-10 9:11 ` Stefan Thomas 0 siblings, 2 replies; 27+ messages in thread From: Gregory Maxwell @ 2012-07-10 3:05 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development 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"— 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-10 3:05 ` Gregory Maxwell @ 2012-07-10 7:12 ` Wladimir 2012-07-10 9:11 ` Stefan Thomas 1 sibling, 0 replies; 27+ messages in thread From: Wladimir @ 2012-07-10 7:12 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4617 bytes --] Just my two cents -- I'm against removing the overview page or moving it to the wiki. I think other open source clients deserve a mention on the bitcoin.org page. Many new people are looking for a good Android client, for example. Rather than randomly searching on Google or the app store, it's much safer to follow the link from bitcoin.org. Others are looking for a light clients because they think the Satoshi one is too heavy. Again, rather than following random links on a search engine or wiki (not all users have the common sense required for this) it may be better if they follow links "audited" (or at least discussed) by this community. I agree with Jim here. The reference client is already first in that it can be downloaded directly from the main page of bitcoin.org. That should stay that way for the considerable future, as it's the most proven. The position in the alt clients list is less important. That said, I'm not a big fan of randomized order because it's confusing. Come back to the page and it's different. Some other neutral ordering is probably possible. Wladimir On Tue, Jul 10, 2012 at 5:05 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > 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"— 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@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 5818 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-10 3:05 ` Gregory Maxwell 2012-07-10 7:12 ` Wladimir @ 2012-07-10 9:11 ` Stefan Thomas 2012-07-13 15:20 ` Daniel F 1 sibling, 1 reply; 27+ messages in thread From: Stefan Thomas @ 2012-07-10 9:11 UTC (permalink / raw) To: bitcoin-development > 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@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@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-10 9:11 ` Stefan Thomas @ 2012-07-13 15:20 ` Daniel F 0 siblings, 0 replies; 27+ messages in thread From: Daniel F @ 2012-07-13 15:20 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2702 bytes --] This discussion is quite bikesheddy, but (or thus? :) ) I will put in my 2c. The main thing to think about, I think, is "what would be best for the users". To that end, I suggest the following: * I do think a page on bitcoin.org listing relatively major, and relatively vetted, clients is a good idea. Removing it completely and relegating it to a wiki page, which is likely to contain all sorts of marginal crufty clients, would likely be a disservice to the users. * Randomized order is likely also a disservice to the users. We should list clients in order of "goodness", as determined by whoever(s) we decide to put in charge of the page. This "goodness" should likely to be some kind of weighted average of features, security, goodness for bitcoin network, etc. [1] ** If randomized order is after all chosen, it should be done in javascript client-side, rather than doing daily page reorgs. If people without JS don't see random, it's not material at all. * Prose vs. feature matrix: both have their good and bad points, as discussed upthread. I think the users will be best served by a combination of both: ** Prose descriptions of clients should deliberately include negative points, not just let the user infer them by lack of corresponding positive mention. (e.g. "This client has fast startup time. That means you're completely trusting the server operator with your money.") This task is left up to the person(s) in charge. ** A feature matrix, with carefully chosen and /well defined/ categories, /in addition to prose/ would likely also be of service to the users. That could be left to the wiki though. The current wiki clients page seems to be having a good go at it.[2] ** If we are targeting people who "don't know what they're doing", it may be a good idea to have a 'decision assistant' type setup, where users are asked several questions and are recommended clients based on these answers. (This could be done in a static way by having a matrix of questions.) Finally - I'd say we're spending disproportionate developer resources on this question, and if it were completely up to me, I'd resolve this situation in the following quick-and-painless way: leave page as is, add negative points to prose, link to wiki clients list. Estimated time to completion: 1 hour (to think through which negative points to add). [1] Meehl, 1954, clinical versus statistical prediction... (see also Grove and Meehl, 1996; Sawyer, 1966) (and yes, despite the age of some of this research, the conclusions have been surprisingly robust and timeproof.) [2] https://en.bitcoin.it/w/index.php?title=Clients&oldid=28615 -nanotube [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 18:18 ` Amir Taaki 2012-07-09 18:30 ` Mike Hearn @ 2012-07-09 18:48 ` Gregory Maxwell 1 sibling, 0 replies; 27+ messages in thread From: Gregory Maxwell @ 2012-07-09 18:48 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki <zgenjix@yahoo•com> wrote: > The only thing that's changed between now and this morning is: > > - Addition of Bitcoin Wallet for Android > - Randomisation of entries Yes, because I reverted eight commits to it by you because they were clearly controversial, including the proprietary clients section and blockchain.info. You went on to add the randomization, again without a pull request and, as seen here, its somewhat controversial. > I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by: Luke originally authored the multiple clients page. It sounded like it could be useful and I made some recommendations for it too. I'm concerned that it's not working out that well. Thus "we should probably consider". Perhaps that came off as too strong. If I really pushing for that I'd submit it as a pull request. (and everyone, including the people you listed, could comment) I think the fact that we can just remove it if we can't agree on it is a useful point to the discussion. For the site to be a neutral resource it should be conservatively operated and if sometimes being neutral, safe, and conservative gets in the way of being complete then we should choose those other things over completeness. There are a great many other resources available, bitcoin.org will never contain all the relevant knowledge. > You're proposing to remove the page.You know, and I know and I know that you know that nobody visits the Wiki. Crazy. I have considerable evidence to the contrary, in fact. The wiki is widely used and promoted as the primary community memory. I certainly didn't agree with that suggestion because I thought it wouldn't get seen. I found it agreeable because it would reflect the lower degree of consensus we apparently have about listing the page. > Have you tried the new clients? I've tried all 4, and they are all well written. I've used multibit, armory, and electrum (though not for some time). I shed painted the electrum determinstic wallet stuff pretty extensively when it was first created, and I think the wordlist seed stuff was my suggestion. > Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has. I'd like to invite you to point your electrum client against a server I operate. I will then happily agree with you that it is more secure: because the bitcoin I rob from you will soothe my pain at the loss of this "debate". Sound like a deal? I think you're exaggerating the features there, and simultaneously underplaying the fact that clients doesn't actually participate in the bitcoin protocol, don't provide the security promises of bitcoin, and basically leave us with a centralized system (if thats all we had). It's a worthwhile part of the ecosystem, I agree. > MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys. There has been QR integration in bitcoin-qt for some time. ::shrugs:: I don't really understand why you're arguing features here: Yes the other clients are great things. I never said they weren't. They are not, however, complete alternatives to the reference client yet. > There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community. Please stop putting words in my mouth. I certainly don't think that. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 16:04 ` Gregory Maxwell 2012-07-09 16:09 ` Amir Taaki @ 2012-07-09 20:44 ` Jeff Garzik 1 sibling, 0 replies; 27+ messages in thread From: Jeff Garzik @ 2012-07-09 20:44 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > If you had authored this as a pull request rather than making the > change unilaterally I would have recommended leaving it so the > reference client was always first. I also would have suggested that it > use JS randomization instead of jekyll in order to get more even > coverage, though I think thats a more minor point. Agreed, and this would be why I support revert -- pull requests are for anything non-trivial. This practice of pull requests clearly should be followed in the case of controversial changes. > Some people were concerned when this page was created that it would > just be a source of useless disputes. I think its becoming clear that > this is the case. I think the cost of dealing with this page is > starting to exceed the benefit it provides and we should probably > consider removing it. Agreed. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 15:54 Amir Taaki 2012-07-09 16:04 ` Gregory Maxwell @ 2012-07-09 17:33 ` Nils Schneider 2012-07-09 18:24 ` Amir Taaki 1 sibling, 1 reply; 27+ messages in thread From: Nils Schneider @ 2012-07-09 17:33 UTC (permalink / raw) To: bitcoin-development I don't think that's a good idea as it can easily confuse or annoy users when things move around. The ordering should be preserved as much as possible so users can remember where they found a client they liked (e.g. 2nd row, 1st column and screenshot with light and blue colors). Making them search the entire page is inefficient and will just get worse once there are many clients on the page (and I think that's the goal). On 09.07.2012 17:54, Amir Taaki wrote: > Took me a while, but finally got it working. > > Entries on the clients page are randomly ordered when the page is generated. > > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > > We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. > > > ------------------------------------------------------------------------------ > 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Random order for clients page 2012-07-09 17:33 ` Nils Schneider @ 2012-07-09 18:24 ` Amir Taaki 0 siblings, 0 replies; 27+ messages in thread From: Amir Taaki @ 2012-07-09 18:24 UTC (permalink / raw) To: bitcoin-development By that time in the future, when there are many clients, there should just be a flat list or no list at all. ----- Original Message ----- From: Nils Schneider <nils@nilsschneider•net> To: bitcoin-development@lists•sourceforge.net Cc: Sent: Monday, July 9, 2012 6:33 PM Subject: Re: [Bitcoin-development] Random order for clients page I don't think that's a good idea as it can easily confuse or annoy users when things move around. The ordering should be preserved as much as possible so users can remember where they found a client they liked (e.g. 2nd row, 1st column and screenshot with light and blue colors). Making them search the entire page is inefficient and will just get worse once there are many clients on the page (and I think that's the goal). On 09.07.2012 17:54, Amir Taaki wrote: > Took me a while, but finally got it working. > > Entries on the clients page are randomly ordered when the page is generated. > > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > > We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-07-13 15:21 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-09 18:54 [Bitcoin-development] Random order for clients page Jim 2012-07-09 18:57 ` Gregory Maxwell 2012-07-09 19:14 ` Alan Reiner 2012-07-09 20:13 ` Gary Rowe -- strict thread matches above, loose matches on Subject: below -- 2012-07-09 15:54 Amir Taaki 2012-07-09 16:04 ` Gregory Maxwell 2012-07-09 16:09 ` Amir Taaki 2012-07-09 16:39 ` Stefan Thomas 2012-07-09 16:55 ` Harald Schilly 2012-07-09 17:21 ` Luke-Jr 2012-07-09 17:46 ` Gregory Maxwell 2012-07-09 18:03 ` Alan Reiner 2012-07-09 18:29 ` thomasV1 2012-07-09 18:18 ` Amir Taaki 2012-07-09 18:30 ` Mike Hearn 2012-07-09 22:26 ` Stefan Thomas 2012-07-09 22:37 ` Mike Hearn 2012-07-10 2:36 ` Stefan Thomas 2012-07-10 2:44 ` Alan Reiner 2012-07-10 3:05 ` Gregory Maxwell 2012-07-10 7:12 ` Wladimir 2012-07-10 9:11 ` Stefan Thomas 2012-07-13 15:20 ` Daniel F 2012-07-09 18:48 ` Gregory Maxwell 2012-07-09 20:44 ` Jeff Garzik 2012-07-09 17:33 ` Nils Schneider 2012-07-09 18:24 ` Amir Taaki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox