new bitcoin.org clients page
34 messages, 30 Apr to 3 May 2012. Started by Amir Taaki.
Alan Reiner (6), Amir Taaki (4), grarpamp (4), Gary Rowe (4), Mike Hearn (3), Luke Dashjr (3), Greg Maxwell (2), Jeff Garzik (2), +4 more
Check it :) https://github.com/bitcoin/bitcoin.org/pull/34
Hey, looks good! I'm glad to see them sorted alphabetically :)
A couple comments: I don't think the entries for "wallet security" and "backups" accurately describe Armory. Wallet Security should say "Encrypt/Offline" or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like "One-time Printable" if it fits within the box.
Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the "reference" client, and I think it's relevant that it is the "de-facto" client for the majority of users, and the one with the most quality control and stability.
-Alan
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (14 lines)
> Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 > > > ------------------------------------------------------------------------------ > 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 >
Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your browser.
Also about the descriptions: yeah I know. I think it's better to put this up first and then have everyone submit their own descriptions and screenshots. Otherwise it'll be a nightmare to coordinate until everything is perfect. I did message you on IRC today but maybe you were offline.
I didn't copy paste the Armory description from the website because it really sounds too spammy like a sales pitch. Here I was trying to give an even handed balanced overview of all the clients. For each client I was trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. MultiBit is ease of use.
________________________________ From: Alan Reiner <etotheipi@gmail•com> To: Amir Taaki <zgenjix@yahoo•com> Cc: "bitcoin-development@lists•sourceforge•net" <bitcoin-development@lists•sourceforge•net> Sent: Monday, April 30, 2012 7:23 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page
Hey, looks good! I'm glad to see them sorted alphabetically :)
A couple comments: I don't think the entries for "wallet security" and "backups" accurately describe Armory. Wallet Security should say "Encrypt/Offline" or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like "One-time Printable" if it fits within the box.
Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the "reference" client, and I think it's relevant that it is the "de-facto" client for the majority of users, and the one with the most quality control and stability.
-Alan
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Check it :) https://github.com/bitcoin/bitcoin.org/pull/34
Quoted text (12 lines)
> >------------------------------------------------------------------------------ >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 >
Actually I was looking at a screenshot someone sent me because I couldn't seem to access it even after changing the hosts file (I assumed it was recent, but I guess not). It just looked like the regular Bitcoin page (despite doing a ping on the command line and seeing the expected IP). Was there a specific link to click on? Am I blind?
Is there a process we should use to submit how we think our program should be represented on the clients page?
-Alan
On Mon, Apr 30, 2012 at 2:31 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (71 lines)
> Are we looking at the same list? Because here is the order I added: > Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a > refresh of your browser. > > Also about the descriptions: yeah I know. I think it's better to put this > up first and then have everyone submit their own descriptions and > screenshots. Otherwise it'll be a nightmare to coordinate until everything > is perfect. I did message you on IRC today but maybe you were offline. > > I didn't copy paste the Armory description from the website because it > really sounds too spammy like a sales pitch. Here I was trying to give an > even handed balanced overview of all the clients. For each client I was > trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. > Electrum is convenient. MultiBit is ease of use. > > ________________________________ > From: Alan Reiner <etotheipi@gmail•com> > To: Amir Taaki <zgenjix@yahoo•com> > Cc: "bitcoin-development@lists•sourceforge•net" < > bitcoin-development@lists•sourceforge•net> > Sent: Monday, April 30, 2012 7:23 PM > Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > > Hey, looks good! I'm glad to see them sorted alphabetically :) > > A couple comments: I don't think the entries for "wallet security" and > "backups" accurately describe Armory. Wallet Security should say > "Encrypt/Offline" or something to to that effect -- after all, offline > wallets are the holy grail feature of the Armory. And backups should say > something like "One-time Printable" if it fits within the box. > > Otherwise, I really like the layout and design. Although despite the fact > I enjoy being first on the list, I think Bitcoin-Qt should still go first. > It is the "reference" client, and I think it's relevant that it is the > "de-facto" client for the majority of users, and the one with the most > quality control and stability. > > -Alan > > > > On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote: > > Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 > > > > >------------------------------------------------------------------------------ > >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 >
We're debating the descriptions on the thread. I provided rewritten descriptions that try and keep with the "theme per client" goal, whilst being less technical.
I think it's unclear how best to run this page. It's clear we need one though. If everyone can just submit whatever they like then we'll end up with 4 or 5 "pick me! pick me!" type descriptions, which avoids a lot of arguing but doesn't really help our users make a decision. If we have a Benign Dictator model we might end up with descriptions that are wrong or don't highlight the strengths / weaknesses of each client properly.
So although it's messy I think the right path is probably the middle one - have some descriptions that try to be neutral, then improve them based on feedback from users and developers. They need to be flexible and evolve over time as the clients evolve too. At some point every client will support deterministic wallets so "easy backups" won't be worth mentioning any more, but there'll be new distinguishing features. And we all need to try and be honest about our own work.
Here is the current content. Like I said, the descriptions are *not* set in stone at all.
Bitcoin-Qt <http://bitcoin.org/>
The original software written by Satoshi Nakamoto, the project's founder. If you aren't sure which program to pick, this is a good bet. This application is a peer-to-peer client that builds the backbone of the Bitcoin network. It is suited for enthusiasts, merchants, miners, developers and people who want to help support the project. People who run Bitcoin-Qt are first class network citizens and have the highest levels of security, privacy and stability. However, it can be very resource intensive and you should be willing to leave it running in the background so other computers can connect to yours. If your computer is low powered or you aren't willing to tolerate a 24-hour+ initial start time, you should consider other clients. Cutting edge features tend to be implemented in other clients first.
Website: bitcoin.org
Platforms: MultiBit <http://multibit.org/>
MultiBit's primary focus is being fast and easy to use, even for people with no technical knowledge. It has a YouTube channel to help you learn the software, and includes helpful features such as an exchange rate ticker. MultiBit supports many languages such as German, Spanish and Greek. MultiBit synchronizes with the network much faster than Bitcoin-Qt and should be ready for you to use within a few minutes. This is a good choice for non technical users who want an easy to use experience, especially if you use a Mac.
Website: multibit.org
Platforms: Armory <http://bitcoinarmory.com/>
Armory focuses on advanced wallet management features, such as the ability to construct transactions whilst disconnected from the internet. It operates in conjunction with a Bitcoin-Qt install. It requires a large amount of RAM to operate and if you use Windows, it requires a 64 bit version. It is a good choice for tech-savvy enthusiasts or merchants who want to try out cutting edge ideas in the Bitcoin world. Armory was partly funded by a community donation drive which raised over $4000.
Website: bitcoinarmory.com
Platforms:
Electrum <http://ecdsa.org/electrum>
Electrum's focus is speed, with low resource usage and making wallet backups easy. It operates in conjunction with remote servers that handle the most complicated parts of the Bitcoin system, which is why it's fast. However, by running this client you don't contribute your computer's resources to the core network, and the remote servers that help give it good performance have the ability to see all your transactions and tie them together. Whilst you need provide no personal information to use Electrum (as is true for all Bitcoin clients), this means the privacy level is lower than for other clients. Merchants are recommended to use other p2p clients. Electrum is not quite user friendly yet - currently it is more suited for tech-saavy individuals.
Website: ecdsa.org/electrum
Platforms:
Quoted text (1 line)
> If your computer is low powered or you aren't willing to tolerate a 24-hour+ initial start time,
What computer is the initial start time 24-hours+ now? On normal systems initial sync-up now takes a couple hours. It could be slower, of course, if you have the bad luck to end up with unresponsive peers— but that will also make the SPV nodes slow.
Better to be conservative I agree, but calling it a dozen times longer than I'd expect is perhaps a bit much.
Refine refine refine.
On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
Quoted text (1 line)
> The original software written by Satoshi Nakamoto, the project's founder.
This is just wrong. While Bitcoin-Qt is by far the best client, it is Wladimir's, not Satoshi's.
Quoted text (2 lines)
> If your computer is low powered or you aren't willing to tolerate a 24-hour+ > initial start time, you should consider other clients.
Isn't this down to only a few hours now?
Quoted text (2 lines)
> Armory was partly funded by a community donation drive which raised over > $4000.
I don't see this as relevant. Every client has been partly funded by donations, anyway.
Quoted text (4 lines)
> > What computer is the initial start time 24-hours+ now? On normal > systems initial sync-up now takes a couple hours. >
OK, I haven't tried a full block chain sync for a while. If it's only a couple of hours that's great. Let's change that.
Quoted text (1 line)
> MultiBit supports many languages such as German, Spanish and Greek.
Bitcoin-qt is translated into a pretty broad set of languages (now— I cant tell you how many of them are _good_). Listing language just under multibit makes it sound like a distinguishing characteristic. Might it be useful to add two info lines to each entry: One with the language codes it supports (ISO 639 please, not flags), and another line with operating system support? (perhaps not, they're all win/mac/linux, enh?) These are both things which are particular suitable to clear objective enumeration.
Quoted text (5 lines)
> > Bitcoin-qt is translated into a pretty broad set of languages (now— I > cant tell you how many of them are _good_). Listing language just > under multibit makes it sound like a distinguishing characteristic. >
Fair enough then, let's take that out.
Btw, I sent updated text to Genjix Armory. I hope that gets included or reviewed.
And I agree about the $4k donations thing. That's complete immaterial for this page. Though the rest of the description there is reasonable, and might even be better than what I sent Genjix.
-Alan
On Wed, May 2, 2012 at 9:42 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (7 lines)
> Bitcoin-qt is translated into a pretty broad set of languages (now— I >> cant tell you how many of them are _good_). Listing language just >> under multibit makes it sound like a distinguishing characteristic. >> > > Fair enough then, let's take that out. >
Quoted text (1 line)
> While Bitcoin-Qt is by far the best client
This is purely subjective. One's best is another's worst.
Quoted text (2 lines)
> These are both things which are particular > suitable to clear objective enumeration.
Yes, so for the purposes of compiling a list of clients and libraries, please just stick to a table of features.
On the subjective part, I'm finding the library+client implementations to be nice, and indeed the future. Afaik, there are two major pairs of these so far that should be listed. Ymmv.
Can someone also please set the reply-to header for these lists. It's really annoying to hit reply and not have the list address show up. Thanks :)
On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
Quoted text (3 lines)
> Can someone also please set the reply-to header > for these lists. It's really annoying to hit reply and > not have the list address show up. Thanks :)
Try "Reply to All"
Quoted text (2 lines)
> it's unclear how best to run this page. It's clear we need one though. > the right path is probably the middle one - have some descriptions that try to be neutral
Do it in two parts... - overview, history, architecture model, 'whys'. - agnostic table of features, platforms, stats, protocols, etc
Last, resolve whether or not bitcoin.org is independant. It cannot be if it does not accept all lib/client under it's umbrella or has a lib/client project of it's own. You will hit up against this, just saying.
Quoted text (2 lines)
> Bitcoin-Qt > This application is a peer-to-peer client that builds the backbone of the Bitcoin network.
No, they all do this and build it, subject to their feature set.
Quoted text (1 line)
> It is suited for enthusiasts, merchants, miners, developers
No, all implementations are suited for whoever, subject to their feature set.
Quoted text (1 line)
> and people who want to help support the project.
Which project, the given client or the bitcoin meme.
Quoted text (1 line)
> People who run Bitcoin-Qt are first class network citizens and have the highest levels of security, privacy and stability.
Right, anyone who doesn't is unwashed rebel scum, running default installs of xp, on systems with bad ram, who post their home address, transaction logs, and pink bits on facebook.
Quoted text (1 line)
> leave it running in the background so other computers can connect to yours.
Again, a feature set / usage model thing.
Quoted text (2 lines)
> MultiBit > fast and easy to use, even for people with no technical knowledge.
Hey, we're fast, easy and for noobs, me too.
Quoted text (1 line)
> It has a...
But at least the backing specifics to that claim are stated.
Quoted text (2 lines)
> Armory > Armory was partly funded by a community donation drive which raised over $4000.
Yeah, every lib/client will have a donation thing on their own site, and the developers own real world wallet.
Quoted text (2 lines)
> Electrum > the privacy level is lower than for other clients.
Not sure of this claim. It's all in the usage. Run your own remote, use anonymizers, etc. Right?
Quoted text (1 line)
> Try "Reply to All"
That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it.
On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
Quoted text (7 lines)
>> Try "Reply to All" > > That puts the sender in 'to' and list in 'cc', > which dupes to the sender and eventually > blows out the to and cc lines as everyone > chimes in and doesn't trim. 'reply to' solves > most of that. assuming the list sw can do it.
"Reply-To" Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
----- Original Message ----- From: Jeff Garzik <jgarzik@exmulti•com> To: grarpamp <grarpamp@gmail•com> Cc: bitcoin-development@lists•sourceforge•net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page
On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote:
Quoted text (7 lines)
>> Try "Reply to All" > > That puts the sender in 'to' and list in 'cc', > which dupes to the sender and eventually > blows out the to and cc lines as everyone > chimes in and doesn't trim. 'reply to' solves > most of that. assuming the list sw can do it.
"Reply-To" Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html
How about keeping it simple?
Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org
MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org
Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/
Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (67 lines)
> This is like the most annoying thing about email. Often with group emails, > we'll be having a conversation then someone will click reply instead of > group reply and the convo will go on for a while. Eventually I'll realise > the persons are missing and add them back in. > > On Yahoo mail (which I use for spam/mailing lists), to do reply all > involves clicking a tab, scrolling down and clicking Reply All. Normally I > instead go through the steps of reply, delete To, re-enter bitco... select > drop down, click send. > > Anyone know how to make reply all the default in mutt? And how can I > exclude it from re-including my own email when I do a group reply so I > don't get the same email again. > > > > ----- Original Message ----- > From: Jeff Garzik <jgarzik@exmulti•com> > To: grarpamp <grarpamp@gmail•com> > Cc: bitcoin-development@lists•sourceforge•net > Sent: Wednesday, May 2, 2012 7:29 PM > Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: > >> Try "Reply to All" > > > > That puts the sender in 'to' and list in 'cc', > > which dupes to the sender and eventually > > blows out the to and cc lines as everyone > > chimes in and doesn't trim. 'reply to' solves > > most of that. assuming the list sw can do it. > > "Reply-To" Munging Considered Harmful > http://www.unicom.com/pw/reply-to-harmful.html > > > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@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 > > > > ------------------------------------------------------------------------------ > 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 >
Oh, like I did 3 hours ago? Gah! I replied directly to grarpamp by accident. Sorry if this seems out of place now...
I'm all for sorting the clients by "ease of use". We want the smoothest first experience greeting users new to Bitcoin. I have grand plans of defaulting Armory to a standard user mode that is standalone, easy to use, etc. But until then, Armory will remain an a power-users thing, and I'd prefer not to have Bitcoin n00bs emailing me for support before they know what Bitcoin-Qt is, or, more likely, installing Armory alone and then walking away when nothing works.
As someone else mentioned previously, the advanced stuff will generally be found by advanced users. I think it should still receive exposure through these means, but not on the top/first row.
I personally think the page should say something like "New to Bitcoin? Start experiencing Bitcoin with My Phone <menu of phone options>, or My Desktop <menu of desktop options>" Put the top 3 on each and either a button for "More Options", or a short list of other options without screenshots, and just descriptions with links. Ideally, it would be sorted by popularity, because that's probably the most important metric that ties together all features into a single number, but we don't have good stats on that. For now, we settle this by putting Bitcoin-Qt up front, and sort everything else by how easy it is for users to get started and perceived popularity and disagreements can be settled by semi-regular rotation.
For now, I don't think ordering is super important. No one here is threatening lawsuits for improper placement, and the rotation will be good to keep the main Bitcoin page looking less stagnant, and slowly exposing repeat visitors to the variety of options available.
--Alan
On Wed, May 2, 2012 at 3:25 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (67 lines)
> This is like the most annoying thing about email. Often with group emails, > we'll be having a conversation then someone will click reply instead of > group reply and the convo will go on for a while. Eventually I'll realise > the persons are missing and add them back in. > > On Yahoo mail (which I use for spam/mailing lists), to do reply all > involves clicking a tab, scrolling down and clicking Reply All. Normally I > instead go through the steps of reply, delete To, re-enter bitco... select > drop down, click send. > > Anyone know how to make reply all the default in mutt? And how can I > exclude it from re-including my own email when I do a group reply so I > don't get the same email again. > > > > ----- Original Message ----- > From: Jeff Garzik <jgarzik@exmulti•com> > To: grarpamp <grarpamp@gmail•com> > Cc: bitcoin-development@lists•sourceforge•net > Sent: Wednesday, May 2, 2012 7:29 PM > Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: > >> Try "Reply to All" > > > > That puts the sender in 'to' and list in 'cc', > > which dupes to the sender and eventually > > blows out the to and cc lines as everyone > > chimes in and doesn't trim. 'reply to' solves > > most of that. assuming the list sw can do it. > > "Reply-To" Munging Considered Harmful > http://www.unicom.com/pw/reply-to-harmful.html > > > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@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 > > > > ------------------------------------------------------------------------------ > 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 >
Too technical if you ask me. We want a webpage for the dumbest end-user I think.
Java? C? What the heck is this? Blockchain? Qt?
Regards, Raphael
On 05/02/2012 09:34 PM, Gary Rowe wrote:
Quoted text (137 lines)
> How about keeping it simple? > > Bitcoin-Qt > * Requires the entire blockchain > * Standalone client > * Designed for continuous operation > * Available for Windows, Mac, Linux with installer > * Developed in C > * Website: https://bitcoin.org > > MultiBit > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use > * Available for Windows, Mac, Linux with installer > * Developed in Java > * Website: http://multibit.org > > Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt > * Designed for occasional use > * Available for Windows (64-bit only), Mac, Linux (self-build) > * Developed in Python > * Website: http://bitcoinarmory.com/ > > Electrum > * Requires no blockchain > * Dependent client of Bitcoin-Qt (on server) > * Designed for occasional use > * Available for Windows, Linux (self-build) > * Developed in Python > * Website: http://ecdsa.org/electrum/ > > Bitcoin Wallet (Android client) > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use on mobile > * Available for Android only > * Developed in Java > * Website: > https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en > <https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en> > > > On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com > <mailto:zgenjix@yahoo.com>> wrote: > > This is like the most annoying thing about email. Often with group > emails, we'll be having a conversation then someone will click > reply instead of group reply and the convo will go on for a while. > Eventually I'll realise the persons are missing and add them back in. > > On Yahoo mail (which I use for spam/mailing lists), to do reply > all involves clicking a tab, scrolling down and clicking Reply > All. Normally I instead go through the steps of reply, delete To, > re-enter bitco... select drop down, click send. > > Anyone know how to make reply all the default in mutt? And how can > I exclude it from re-including my own email when I do a group > reply so I don't get the same email again. > > > > ----- Original Message ----- > From: Jeff Garzik <jgarzik@exmulti•com <mailto:jgarzik@exmulti.com>> > To: grarpamp <grarpamp@gmail•com <mailto:grarpamp@gmail.com>> > Cc: bitcoin-development@lists•sourceforge•net > <mailto:bitcoin-development@lists.sourceforge.net> > Sent: Wednesday, May 2, 2012 7:29 PM > Subject: Re: [Bitcoin-development] new bitcoin.org > <http://bitcoin.org> clients page > > On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com > <mailto:grarpamp@gmail.com>> wrote: > >> Try "Reply to All" > > > > That puts the sender in 'to' and list in 'cc', > > which dupes to the sender and eventually > > blows out the to and cc lines as everyone > > chimes in and doesn't trim. 'reply to' solves > > most of that. assuming the list sw can do it. > > "Reply-To" Munging Considered Harmful > http://www.unicom.com/pw/reply-to-harmful.html > > > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti•com <mailto:jgarzik@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 > <mailto: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 > <mailto: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
Or we could just point everyone here: http://lovebitcoins.org/getStarted.html
:-)
On 2 May 2012 20:40, Raphael NICOLLE <raphbot@gmail•com> wrote:
Quoted text (140 lines)
> Too technical if you ask me. We want a webpage for the dumbest end-user I > think. > > Java? C? What the heck is this? Blockchain? Qt? > > Regards, > Raphael > > > On 05/02/2012 09:34 PM, Gary Rowe wrote: > > How about keeping it simple? > > Bitcoin-Qt > * Requires the entire blockchain > * Standalone client > * Designed for continuous operation > * Available for Windows, Mac, Linux with installer > * Developed in C > * Website: https://bitcoin.org > > MultiBit > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use > * Available for Windows, Mac, Linux with installer > * Developed in Java > * Website: http://multibit.org > > Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt > * Designed for occasional use > * Available for Windows (64-bit only), Mac, Linux (self-build) > * Developed in Python > * Website: http://bitcoinarmory.com/ > > Electrum > * Requires no blockchain > * Dependent client of Bitcoin-Qt (on server) > * Designed for occasional use > * Available for Windows, Linux (self-build) > * Developed in Python > * Website: http://ecdsa.org/electrum/ > > Bitcoin Wallet (Android client) > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use on mobile > * Available for Android only > * Developed in Java > * Website: > https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en > > > On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote: > >> This is like the most annoying thing about email. Often with group >> emails, we'll be having a conversation then someone will click reply >> instead of group reply and the convo will go on for a while. Eventually >> I'll realise the persons are missing and add them back in. >> >> On Yahoo mail (which I use for spam/mailing lists), to do reply all >> involves clicking a tab, scrolling down and clicking Reply All. Normally I >> instead go through the steps of reply, delete To, re-enter bitco... select >> drop down, click send. >> >> Anyone know how to make reply all the default in mutt? And how can I >> exclude it from re-including my own email when I do a group reply so I >> don't get the same email again. >> >> >> >> ----- Original Message ----- >> From: Jeff Garzik <jgarzik@exmulti•com> >> To: grarpamp <grarpamp@gmail•com> >> Cc: bitcoin-development@lists•sourceforge•net >> Sent: Wednesday, May 2, 2012 7:29 PM >> Subject: Re: [Bitcoin-development] new bitcoin.org clients page >> >> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: >> >> Try "Reply to All" >> > >> > That puts the sender in 'to' and list in 'cc', >> > which dupes to the sender and eventually >> > blows out the to and cc lines as everyone >> > chimes in and doesn't trim. 'reply to' solves >> > most of that. assuming the list sw can do it. >> >> "Reply-To" Munging Considered Harmful >> http://www.unicom.com/pw/reply-to-harmful.html >> >> >> >> -- >> Jeff Garzik >> exMULTI, Inc. >> jgarzik@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 >> >> >> >> ------------------------------------------------------------------------------ >> 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 listBitcoin-development@lists•sourceforge•nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
I'm not sure what "designed for occasional use" means. Many users of other clients use them exclusively without touching other clients. Armory is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd). I'm sure the other clients are the same.
Instead, I think that line would be replaced by a blurb about the target audience. "Designed for Advanced Users". "Designed for Quick Setup and Instant usability".
Btw, Armory now has full installers for both Windows and Linux (Ubuntu/Debian), with uninstallers and automatic URI registration
On Wed, May 2, 2012 at 3:34 PM, Gary Rowe <g.rowe@froot•co•uk> wrote:
Quoted text (128 lines)
> How about keeping it simple? > > Bitcoin-Qt > * Requires the entire blockchain > * Standalone client > * Designed for continuous operation > * Available for Windows, Mac, Linux with installer > * Developed in C > * Website: https://bitcoin.org > > MultiBit > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use > * Available for Windows, Mac, Linux with installer > * Developed in Java > * Website: http://multibit.org > > Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt > * Designed for occasional use > * Available for Windows (64-bit only), Mac, Linux (self-build) > * Developed in Python > * Website: http://bitcoinarmory.com/ > > Electrum > * Requires no blockchain > * Dependent client of Bitcoin-Qt (on server) > * Designed for occasional use > * Available for Windows, Linux (self-build) > * Developed in Python > * Website: http://ecdsa.org/electrum/ > > Bitcoin Wallet (Android client) > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use on mobile > * Available for Android only > * Developed in Java > * Website: > https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en > > > On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote: > >> This is like the most annoying thing about email. Often with group >> emails, we'll be having a conversation then someone will click reply >> instead of group reply and the convo will go on for a while. Eventually >> I'll realise the persons are missing and add them back in. >> >> On Yahoo mail (which I use for spam/mailing lists), to do reply all >> involves clicking a tab, scrolling down and clicking Reply All. Normally I >> instead go through the steps of reply, delete To, re-enter bitco... select >> drop down, click send. >> >> Anyone know how to make reply all the default in mutt? And how can I >> exclude it from re-including my own email when I do a group reply so I >> don't get the same email again. >> >> >> >> ----- Original Message ----- >> From: Jeff Garzik <jgarzik@exmulti•com> >> To: grarpamp <grarpamp@gmail•com> >> Cc: bitcoin-development@lists•sourceforge•net >> Sent: Wednesday, May 2, 2012 7:29 PM >> Subject: Re: [Bitcoin-development] new bitcoin.org clients page >> >> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: >> >> Try "Reply to All" >> > >> > That puts the sender in 'to' and list in 'cc', >> > which dupes to the sender and eventually >> > blows out the to and cc lines as everyone >> > chimes in and doesn't trim. 'reply to' solves >> > most of that. assuming the list sw can do it. >> >> "Reply-To" Munging Considered Harmful >> http://www.unicom.com/pw/reply-to-harmful.html >> >> >> >> -- >> Jeff Garzik >> exMULTI, Inc. >> jgarzik@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 >> >> >> >> ------------------------------------------------------------------------------ >> 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 > >
This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable).
If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details:
http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: You suggest creating something new for your hackerspace, like a bikeshed. But now all anyone will discuss is its colour. No bikeshed will be built.
Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum.
________________________________ From: Gary Rowe <g.rowe@froot•co•uk> To: "bitcoin-development@lists•sourceforge•net" <bitcoin-development@lists•sourceforge•net> Sent: Wednesday, May 2, 2012 8:34 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page
How about keeping it simple?
Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org
MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org
Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/
Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote:
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
Quoted text (58 lines)
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. > >Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. > > > > >----- Original Message ----- >From: Jeff Garzik <jgarzik@exmulti•com> >To: grarpamp <grarpamp@gmail•com> >Cc: bitcoin-development@lists•sourceforge•net >Sent: Wednesday, May 2, 2012 7:29 PM >Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: >>> Try "Reply to All" >> >> That puts the sender in 'to' and list in 'cc', >> which dupes to the sender and eventually >> blows out the to and cc lines as everyone >> chimes in and doesn't trim. 'reply to' solves >> most of that. assuming the list sw can do it. > >"Reply-To" Munging Considered Harmful >http://www.unicom.com/pw/reply-to-harmful.html > > > >-- >Jeff Garzik >exMULTI, Inc. >jgarzik@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 > > >------------------------------------------------------------------------------ >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 >
Alan, apologies about the installer - I was just using your website info to infer how it all fitted together.
On 2 May 2012 20:43, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (166 lines)
> This discussion about ordering is absolutely retarded. Once the list fills > up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt > first and the others ordered however. That was nobody can try to game the > system (it remains unexploitable). > > If there are no objections, then I am going to merge this branch. The > forum thread is divulging into a mess all over the place, and this > conversation can go on forever discussing the silly fine details: > > http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: > You suggest creating something new for your hackerspace, like a > bikeshed. But now all anyone will discuss is its colour. No bikeshed > will be built. > > Armory & MultiBit, are you OK with that description? I will check with > ThomasV about Electrum. > > > ________________________________ > From: Gary Rowe <g.rowe@froot•co•uk> > To: "bitcoin-development@lists•sourceforge•net" < > bitcoin-development@lists•sourceforge•net> > Sent: Wednesday, May 2, 2012 8:34 PM > Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > > How about keeping it simple? > > Bitcoin-Qt > * Requires the entire blockchain > * Standalone client > * Designed for continuous operation > * Available for Windows, Mac, Linux with installer > * Developed in C > * Website: https://bitcoin.org > > MultiBit > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use > * Available for Windows, Mac, Linux with installer > * Developed in Java > * Website: http://multibit.org > > Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt > * Designed for occasional use > * Available for Windows (64-bit only), Mac, Linux (self-build) > * Developed in Python > * Website: http://bitcoinarmory.com/ > > Electrum > * Requires no blockchain > * Dependent client of Bitcoin-Qt (on server) > * Designed for occasional use > * Available for Windows, Linux (self-build) > * Developed in Python > * Website: http://ecdsa.org/electrum/ > > Bitcoin Wallet (Android client) > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use on mobile > * Available for Android only > * Developed in Java > * Website: > https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en > > > On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote: > > This is like the most annoying thing about email. Often with group emails, > we'll be having a conversation then someone will click reply instead of > group reply and the convo will go on for a while. Eventually I'll realise > the persons are missing and add them back in. > > > >On Yahoo mail (which I use for spam/mailing lists), to do reply all > involves clicking a tab, scrolling down and clicking Reply All. Normally I > instead go through the steps of reply, delete To, re-enter bitco... select > drop down, click send. > > > >Anyone know how to make reply all the default in mutt? And how can I > exclude it from re-including my own email when I do a group reply so I > don't get the same email again. > > > > > > > > > >----- Original Message ----- > >From: Jeff Garzik <jgarzik@exmulti•com> > >To: grarpamp <grarpamp@gmail•com> > >Cc: bitcoin-development@lists•sourceforge•net > >Sent: Wednesday, May 2, 2012 7:29 PM > >Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > > > > >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: > >>> Try "Reply to All" > >> > >> That puts the sender in 'to' and list in 'cc', > >> which dupes to the sender and eventually > >> blows out the to and cc lines as everyone > >> chimes in and doesn't trim. 'reply to' solves > >> most of that. assuming the list sw can do it. > > > >"Reply-To" Munging Considered Harmful > >http://www.unicom.com/pw/reply-to-harmful.html > > > > > > > >-- > >Jeff Garzik > >exMULTI, Inc. > >jgarzik@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 > > > > > > >------------------------------------------------------------------------------ > >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 >
I think it's perfectly reasonable to debate ordering. I personally don't think Armory should be up front, because it's not intended for beginners. How's that for honesty? I don't think anyone is trying to game the system right now, I think we're trying to come up with a reasonable mechanism for appealing to new users and get the community more connected. And make sure everyone understands the system.
On the other hand, perhaps it's better to take the acceptable 80% solution, and revise it over time...
Amir, I don't have access to the page. I've never been able to view it. Changing my hosts file doesn't seem to do anything. Can you just forward me the text? I'll send you an approval email.
On Wed, May 2, 2012 at 3:43 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (166 lines)
> This discussion about ordering is absolutely retarded. Once the list fills > up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt > first and the others ordered however. That was nobody can try to game the > system (it remains unexploitable). > > If there are no objections, then I am going to merge this branch. The > forum thread is divulging into a mess all over the place, and this > conversation can go on forever discussing the silly fine details: > > http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: > You suggest creating something new for your hackerspace, like a > bikeshed. But now all anyone will discuss is its colour. No bikeshed > will be built. > > Armory & MultiBit, are you OK with that description? I will check with > ThomasV about Electrum. > > > ________________________________ > From: Gary Rowe <g.rowe@froot•co•uk> > To: "bitcoin-development@lists•sourceforge•net" < > bitcoin-development@lists•sourceforge•net> > Sent: Wednesday, May 2, 2012 8:34 PM > Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > > How about keeping it simple? > > Bitcoin-Qt > * Requires the entire blockchain > * Standalone client > * Designed for continuous operation > * Available for Windows, Mac, Linux with installer > * Developed in C > * Website: https://bitcoin.org > > MultiBit > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use > * Available for Windows, Mac, Linux with installer > * Developed in Java > * Website: http://multibit.org > > Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt > * Designed for occasional use > * Available for Windows (64-bit only), Mac, Linux (self-build) > * Developed in Python > * Website: http://bitcoinarmory.com/ > > Electrum > * Requires no blockchain > * Dependent client of Bitcoin-Qt (on server) > * Designed for occasional use > * Available for Windows, Linux (self-build) > * Developed in Python > * Website: http://ecdsa.org/electrum/ > > Bitcoin Wallet (Android client) > * Requires a reduced blockchain > * Standalone client > * Designed for occasional use on mobile > * Available for Android only > * Developed in Java > * Website: > https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en > > > On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote: > > This is like the most annoying thing about email. Often with group emails, > we'll be having a conversation then someone will click reply instead of > group reply and the convo will go on for a while. Eventually I'll realise > the persons are missing and add them back in. > > > >On Yahoo mail (which I use for spam/mailing lists), to do reply all > involves clicking a tab, scrolling down and clicking Reply All. Normally I > instead go through the steps of reply, delete To, re-enter bitco... select > drop down, click send. > > > >Anyone know how to make reply all the default in mutt? And how can I > exclude it from re-including my own email when I do a group reply so I > don't get the same email again. > > > > > > > > > >----- Original Message ----- > >From: Jeff Garzik <jgarzik@exmulti•com> > >To: grarpamp <grarpamp@gmail•com> > >Cc: bitcoin-development@lists•sourceforge•net > >Sent: Wednesday, May 2, 2012 7:29 PM > >Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > > > > >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp@gmail•com> wrote: > >>> Try "Reply to All" > >> > >> That puts the sender in 'to' and list in 'cc', > >> which dupes to the sender and eventually > >> blows out the to and cc lines as everyone > >> chimes in and doesn't trim. 'reply to' solves > >> most of that. assuming the list sw can do it. > > > >"Reply-To" Munging Considered Harmful > >http://www.unicom.com/pw/reply-to-harmful.html > > > > > > > >-- > >Jeff Garzik > >exMULTI, Inc. > >jgarzik@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 > > > > > > >------------------------------------------------------------------------------ > >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 >
On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
Quoted text (2 lines)
> Bitcoin-Qt > * Developed in C
This is far less relevant than license...
Quoted text (3 lines)
> Armory > * Requires the entire blockchain > * Dependent client of Bitcoin-Qt
Or bitcoind?
Quoted text (2 lines)
> Electrum > * Dependent client of Bitcoin-Qt (on server)
Dependent on centralized server, not any particular client
Quoted text (1 line)
> Bitcoin Wallet (Android client)
There are multiple Android clients. There is (or was) an OS selection to the left of the client choices...
On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote:
Quoted text (4 lines)
> I'm not sure what "designed for occasional use" means. Many users of > other clients use them exclusively without touching other clients. Armory > is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd). > I'm sure the other clients are the same.
Pretty sure it means "not running continuously".
Quoted text (2 lines)
> Btw, Armory now has full installers for both Windows and Linux > (Ubuntu/Debian), with uninstallers and automatic URI registration
Would be awesome if it took after Spesmilo and managed bitcoind itself in the background...
Now that I've seen and read through the forum thread on this, I think I'll step back and let others get on with it. As Amir notes, we could be "Bike Shedding" this for years.
On 2 May 2012 21:25, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (41 lines)
> On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote: > > Bitcoin-Qt > > * Developed in C > > This is far less relevant than license... > > > Armory > > * Requires the entire blockchain > > * Dependent client of Bitcoin-Qt > > Or bitcoind? > > > Electrum > > * Dependent client of Bitcoin-Qt (on server) > > Dependent on centralized server, not any particular client > > > Bitcoin Wallet (Android client) > > There are multiple Android clients. There is (or was) an OS selection to > the > left of the client choices... > > On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote: > > I'm not sure what "designed for occasional use" means. Many users of > > other clients use them exclusively without touching other clients. > Armory > > is designed to be your only wallet (if bitcoind[d/-qt] is running in > bkgd). > > I'm sure the other clients are the same. > > Pretty sure it means "not running continuously". > > > Btw, Armory now has full installers for both Windows and Linux > > (Ubuntu/Debian), with uninstallers and automatic URI registration > > Would be awesome if it took after Spesmilo and managed bitcoind itself in > the > background... > >
Hi Amir,
I am fine with the MultiBit description (+ subsequent suggestions like taking the language text out).
Looking forward to seeing it on the bitcoin.org site.
Jim
jim618@fastmail•co•uk
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (1 line)
> Check it :) https://github.com/bitcoin/bitcoin.org/pull/34
Personally, all this seems far too focused on a centralized website (bitcoin.org), and presents far too many choices at once to the user.
On bitcoin.org (registered by Satoshi), I would rather see the Satoshi reference client and perhaps an "other clients" link on the wiki.
Modern websites are working hard to _reduce_ the number of download links, not _increase_ them. See, e.g. http://fedoraproject.org/en/get-fedora where a single download choice is presented, and then an "other options" link is below the great big download button.
Rather than fighting over what a particular bitcoin.org page should look like, why not maintain an independently managed BitcoinClients.org website? Or GetBitcoinClient.org or somesuch.
Solve this problem in a distributed fashion, rather than stuffing it all onto bitcoin.org. Bitcoin.org, IMO, is the home of the "reference project" not the entire bitcoin community. Emphasizing that months ago was why the forum was moved to bitcointalk.org.
On 05/02/2012 03:22 PM, Mike Hearn wrote:
Quoted text (3 lines)
> We're debating the descriptions on the thread. I provided rewritten > descriptions that try and keep with the "theme per client" goal, whilst > being less technical.
Can we add Bitcoin Wallet? I'm not very good at writing descriptions, so I would just add this for starters:
Quoted text (2 lines)
> "Reply-To" Munging Considered Harmful > http://www.unicom.com/pw/reply-to-harmful.html
Ok, ok. but only because this reminds me of the top-posting and formatting advice page that I can't seem to find right now.
But I'm not munging what my client decides to put in to/cc on a g reply either :)
On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
Quoted text (1 line)
> Can we add Bitcoin Wallet?
Someone said to me that the cell phone apps they had tried were still too slow. I'm still using an old phone so I didn't know well what to answer him. I recomended him bitcoin wallet and bitcoin spinner, but I warned him that I haven't really used them.
It would be nice to also have a list with smartphone clients near the list that is being prepared.
On 05/03/2012 11:24 AM, Jorge Timón wrote:
Quoted text (6 lines)
> On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote: >> Can we add Bitcoin Wallet? > > Someone said to me that the cell phone apps they had tried were still > too slow. I'm still using an old phone so I didn't know well what to > answer him.
I never measured exactly, but Bitcoin Wallet takes about an hour to update its blockchain initially on good WLAN (lightweight approach, headers only).
After that, Bitcoin Wallet is just as fast as any other client.
The advantage of that approach is that you are not dependent on any server (like Spinner or Electrum). Essentially you're carrying the blockchain in your pocket.
Cheers,
Andreas
Maybe he didn't configured them well or didn't tried the right ones. He said that on the freicoin forum: http://www.freicoin.org/mobile-app-t28.html
Back to topic... What do you think about including some smartphone clients in the list?
On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote:
Quoted text (34 lines)
> On 05/03/2012 11:24 AM, Jorge Timón wrote: >> On 5/3/12, Andreas Schildbach <andreas@schildbach•de> wrote: >>> Can we add Bitcoin Wallet? >> >> Someone said to me that the cell phone apps they had tried were still >> too slow. I'm still using an old phone so I didn't know well what to >> answer him. > > I never measured exactly, but Bitcoin Wallet takes about an hour to > update its blockchain initially on good WLAN (lightweight approach, > headers only). > > After that, Bitcoin Wallet is just as fast as any other client. > > The advantage of that approach is that you are not dependent on any > server (like Spinner or Electrum). Essentially you're carrying the > blockchain in your pocket. > > Cheers, > > Andreas > > > ------------------------------------------------------------------------------ > 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 >