Re: [Bitcoin-development] Random order for clients page
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"— 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
Re: [Bitcoin-development] Random order for clients page
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: " and users who will benefit will most definitely click on it. I think that's win-win. -- 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
Re: [Bitcoin-development] Random order for clients page
> 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. > -- 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
Re: [Bitcoin-development] Random order for clients page
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 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 -- 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
[Bitcoin-development] Wiki client list (was: Random order for clients page)
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
Re: [Bitcoin-development] Random order for clients page
> 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. -- 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
Re: [Bitcoin-development] Random order for clients page
> 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 >
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell 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. jgar...@exmulti.com -- 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
Re: [Bitcoin-development] Random order for clients page
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 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 wrote: > >> On Mon, Jul 9, 2012 at 2:54 PM, Jim 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 > > -- 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
Re: [Bitcoin-development] Random order for clients page
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 wrote: > On Mon, Jul 9, 2012 at 2:54 PM, Jim 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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 2:54 PM, Jim 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
Re: [Bitcoin-development] Random order for clients page
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.orgMoney, reinvented -- 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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki 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. -- 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
Re: [Bitcoin-development] Random order for clients page
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
Re: [Bitcoin-development] Random order for clients page
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 > An: Gregory Maxwell > CC: "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 > > > > -- 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
Re: [Bitcoin-development] Random order for clients page
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 To: Amir Taaki Cc: "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 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
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
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 On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell wrote: > On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki 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 > -- 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/50
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki 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
Re: [Bitcoin-development] Random order for clients page
FWIW, all this argumenting is why my original suggestion for a Clients list focussed on objective information in alphabetical order. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 11:21 AM, Amir Taaki wrote: > Is the sourcecode for this client available for review? I couldn't find it. yes: http://code.google.com/p/bitcoin-wallet/ and it is built upon http://code.google.com/p/bitcoinj/ harald -- 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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 6:39 PM, Stefan Thomas 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 -- 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
Re: [Bitcoin-development] Random order for clients page
> 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 > To: Amir Taaki > Cc: "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 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 > -- 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
Re: [Bitcoin-development] Random order for clients page
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 To: Amir Taaki Cc: "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 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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 11:54 AM, 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. 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
[Bitcoin-development] Random order for clients page
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
Re: [Bitcoin-development] Bitcoin Wallet for Android
Any chance the blockchain.info iphone app could be included on the clients page? The source is available under an lGPL license: https://github.com/blockchain/My-Wallet-iPhone. More info:https://blockchain.info/wallet/iphone-app Also the javascript web front end can be reviewed using a combination of https://github.com/blockchain/My-Wallet and https://github.com/blockchain/My-Wallet-Integrity-Checker but I could see why that might be more of an issue for the the official site. Thank You, Ben Reeves On 9 Jul 2012, at 15:00, Gregory Maxwell wrote: > On Mon, Jul 9, 2012 at 5:21 AM, Amir Taaki wrote: >> Hey, >> >> I just saw this added to the clients page. One of the conditions we set for >> that page was that all the clients must have the entire sourcecode available >> for review, and users should be able to run it from the sourcecode. Is the >> sourcecode for this client available for review? I couldn't find it. > > I've reverted these additions to the page, nothing personal but— > > At the moment I'm strongly opposed to including any non-reviewable > client options (including centrally operated web services) on the > page, and I think this need to be discussed along with establishing > requirements. > > -- > 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell wrote: > I've reverted these additions to the page, nothing personal but— Er, to be clear, I left the android software in because the source is available (And I'm told its had some review). I removed the proprietary software section the plug for the blockchain.info webservices, and the demotion of the armory client. As far as criteria goes, I don't think we should list anything with a security model weaker than SPV unless users can practically operate their own servers. …and even that I'm a little uneasy with, because most people will use the defaults. Ideally even thin clients would have a near SPV security model, just without the bandwidth. But since the alternative for thin clients is centralized web services the lower standard will probably have better net results for now. Nor do I think we should list anything which can't currently be subjected to independent review of the whole stack (e.g. including the server components in thinclients, unless the server is untrusted). In the future this should be raised to there existing actual evidence of third party review. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 5:21 AM, Amir Taaki wrote: > Hey, > > I just saw this added to the clients page. One of the conditions we set for > that page was that all the clients must have the entire sourcecode available > for review, and users should be able to run it from the sourcecode. Is the > sourcecode for this client available for review? I couldn't find it. I've reverted these additions to the page, nothing personal but— At the moment I'm strongly opposed to including any non-reviewable client options (including centrally operated web services) on the page, and I think this need to be discussed along with establishing requirements. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón wrote: > Didn't even know that they were proprietary software bitcoin clients. > Should people trust them? Should the web promote them? > After all, you can't know what they do. What if one of them contains a > back door or something? > I would say it's better not risk to apologize later. I agree too. Not that being open is _any_ guarantee, ideally we'd want standards of review and testing, but thats a bit much to ask for right now. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
I agree. Just imagine those two-inches newspaper titles - "Bitcoin hacked! Backdoor in official bitcoin client!". We have already some experience with shortcuts which journalists do... slush On Mon, Jul 9, 2012 at 1:34 PM, Jorge Timón wrote: > Should the web promote them? > After all, you can't know what they do. What if one of them contains a > back door or something? -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
Didn't even know that they were proprietary software bitcoin clients. Should people trust them? Should the web promote them? After all, you can't know what they do. What if one of them contains a back door or something? I would say it's better not risk to apologize later. On 7/9/12, Andreas Schildbach wrote: > I'd suggest adding two links for each client. > > One for getting the binary, and one for getting the source. (Obviously, > source being optional if you allow non-opensource clients.) > > > On 07/09/2012 12:44 PM, Amir Taaki wrote: >> OK thanks. I just went and made those sections then saw your posts. >> >> Anyway we have a section for proprietary clients now. Please tell me if >> anything looks disagreeable, http://bitcoin.org/clients.html >> >> One thing I'm going to do is randomise the positioning order within >> sections upon refresh. >> >> >> >> - Original Message - >> From: "m...@henricson.se" >> To: bitcoin-development@lists.sourceforge.net >> Cc: >> Sent: Monday, July 9, 2012 11:19 AM >> Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android >> >> Sources are available here: >> >> http://code.google.com/p/bitcoin-wallet/ >> >> Mats >> >> Quoting Amir Taaki : >> >>> Hey, >>> >>> I just saw this added to the clients page. One of the conditions we >>> set for that page was that all the clients must have the entire >>> sourcecode available for review, and users should be able to run it >>> from the sourcecode. Is the sourcecode for this client available for >>> review? I couldn't find it. >>> >>> Otherwise, we should make a separate section for non-opensource 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 >>> >> >> >> >> -- >> 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/ >> > > > > > -- > 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 > -- Jorge Timón -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
I'd suggest adding two links for each client. One for getting the binary, and one for getting the source. (Obviously, source being optional if you allow non-opensource clients.) On 07/09/2012 12:44 PM, Amir Taaki wrote: > OK thanks. I just went and made those sections then saw your posts. > > Anyway we have a section for proprietary clients now. Please tell me if > anything looks disagreeable, http://bitcoin.org/clients.html > > One thing I'm going to do is randomise the positioning order within sections > upon refresh. > > > > - Original Message - > From: "m...@henricson.se" > To: bitcoin-development@lists.sourceforge.net > Cc: > Sent: Monday, July 9, 2012 11:19 AM > Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android > > Sources are available here: > > http://code.google.com/p/bitcoin-wallet/ > > Mats > > Quoting Amir Taaki : > >> Hey, >> >> I just saw this added to the clients page. One of the conditions we >> set for that page was that all the clients must have the entire >> sourcecode available for review, and users should be able to run it >> from the sourcecode. Is the sourcecode for this client available for >> review? I couldn't find it. >> >> Otherwise, we should make a separate section for non-opensource 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 >> > > > > -- > 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/ > -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
OK thanks. I just went and made those sections then saw your posts. Anyway we have a section for proprietary clients now. Please tell me if anything looks disagreeable, http://bitcoin.org/clients.html One thing I'm going to do is randomise the positioning order within sections upon refresh. - Original Message - From: "m...@henricson.se" To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 11:19 AM Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki : > Hey, > > I just saw this added to the clients page. One of the conditions we > set for that page was that all the clients must have the entire > sourcecode available for review, and users should be able to run it > from the sourcecode. Is the sourcecode for this client available for > review? I couldn't find it. > > Otherwise, we should make a separate section for non-opensource 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 > -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki : > Hey, > > I just saw this added to the clients page. One of the conditions we > set for that page was that all the clients must have the entire > sourcecode available for review, and users should be able to run it > from the sourcecode. Is the sourcecode for this client available for > review? I couldn't find it. > > Otherwise, we should make a separate section for non-opensource 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 > -- 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
[Bitcoin-development] Bitcoin Wallet for Android
Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource 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
