[Bitcoin-development] new bitcoin.org clients page

[Bitcoin-development] new bitcoin.org clients page

[Amir Taaki]

Check it :) https://github.com/bitcoin/bitcoin.org/pull/34

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2253 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Amir Taaki]

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
>

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 3819 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 5379 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4040 bytes --]

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:

[-- Attachment #2: Type: text/html, Size: 10611 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Gregory Maxwell]

> 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.

Re: [Bitcoin-development] new bitcoin.org clients page

[Luke-Jr]

On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
> 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.

> 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?

> 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.

Re: [Bitcoin-development] new bitcoin.org clients page

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 439 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Gregory Maxwell]

> 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.

Re: [Bitcoin-development] new bitcoin.org clients page

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 435 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

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:

> 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.
>

[-- Attachment #2: Type: text/html, Size: 1120 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[grarpamp]

> While Bitcoin-Qt is by far the best client

This is purely subjective. One's best is another's worst.

> 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 :)

Re: [Bitcoin-development] new bitcoin.org clients page

[Luke-Jr]

On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
> 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"

Re: [Bitcoin-development] new bitcoin.org clients page

[grarpamp]

> 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.


> 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.

> It is suited for enthusiasts, merchants, miners, developers

No, all implementations are suited for whoever, subject to their feature set.

>  and people who want to help support the project.

Which project, the given client or the bitcoin meme.

> 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.

> leave it running in the background so other computers can connect to yours.

Again, a feature set / usage model thing.


> MultiBit
> fast and easy to use, even for people with no technical knowledge.

Hey, we're fast, easy and for noobs, me too.

> It has a...

But at least the backing specifics to that claim are stated.


> 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.

> 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?

Re: [Bitcoin-development] new bitcoin.org clients page

[grarpamp]

> 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.

Re: [Bitcoin-development] new bitcoin.org clients page

[Jeff Garzik]

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

Re: [Bitcoin-development] new bitcoin.org clients page

[Amir Taaki]

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

Re: [Bitcoin-development] new bitcoin.org clients page

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 3869 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6014 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 4548 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 6423 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Raphael NICOLLE]

[-- Attachment #1: Type: text/plain, Size: 5406 bytes --]

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 
> <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

[-- Attachment #2: Type: text/html, Size: 9704 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 4997 bytes --]

Or we could just point everyone here:
http://lovebitcoins.org/getStarted.html

:-)

On 2 May 2012 20:40, Raphael NICOLLE <raphbot@gmail.com> wrote:

>  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
>
>

[-- Attachment #2: Type: text/html, Size: 9476 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 5266 bytes --]

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:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 8122 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Amir Taaki]

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

Re: [Bitcoin-development] new bitcoin.org clients page

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 6500 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 9563 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 7113 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 10309 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Luke-Jr]

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...

Re: [Bitcoin-development] new bitcoin.org clients page

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

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:

> 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...
>
>

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: [Bitcoin-development] new bitcoin.org clients page

[Jeff Garzik]

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

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.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] new bitcoin.org clients page

[Andreas Schildbach]

On 05/02/2012 03:22 PM, Mike Hearn wrote:
> 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:

--
Bitcoin Wallet is a standalone wallet for Android devices. Its primary
focus is ease of use and being independant of central network components
(servers). It supports initiating transactions via QR code,  Bitcoin
URIs or near-field communication (NFC). It has a useful currency
conversion calculator.

Platforms: Android
Market: https://play.google.com/store/apps/details?id=de.schildbach.wallet
Project: http://code.google.com/p/bitcoin-wallet/
--

Re: [Bitcoin-development] new bitcoin.org clients page

[grarpamp]

> "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 :)

Re: [Bitcoin-development] new bitcoin.org clients page

[Jorge Timón]

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 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.

-- 
Jorge Timón

Re: [Bitcoin-development] new bitcoin.org clients page

[Andreas Schildbach]

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

Re: [Bitcoin-development] new bitcoin.org clients page

[Jorge Timón]

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:
> 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
>


-- 
Jorge Timón

Re: [Bitcoin-development] new bitcoin.org clients page

[Jim]

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