Re: [Bitcoin-development] URI Handling in Bitcoin-Qt

2012-05-02 Thread Wladimir
On Thu, May 3, 2012 at 6:28 AM, Alan Reiner  wrote:

> **
> *(1) *What is the status & plans for supporting "bitcoin:" URIs in the
> Satoshi client?  My understanding is that it currently creates URIs, but
> does *not* register itself with the OS to handle such links.  Is this
> accurate?  This seems like a very high-value feature, and I'd recommend
> that we consider it a priority -- I can't think of any other upgrade that
> can improve usability so dramatically on the desktop.
>

It is already implemented for Linux (Gnome) and Windows, but there is an
issue with boost::ipc that crashed bitcoin at startup on windows, so it's
temporarily disabled on Windows.


> *(2) *I need to understand better what the intentions were behind
> "label=" and "message=".  The way I understand it is that Bitcoin-Qt uses
> and stores only address-labels, and no other transactional info is stored
> in the wallet.  As such, the "message=" field would be displayed to the
> user when a "bitcoin:" link is clicked, but that message wouldn't be saved
> anywhere.
>

Label is a label for the destination address, message is a freeform message
describing the transaction.

I don't think the message is currently stored in the Satoshi client. That
feature is somewhere on our way-too-long issue and todo list.

But I understand that you want to add transaction meta-data fields such as
contact information, bought items, item prices?

Wladimir
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] URI Handling in Bitcoin-Qt

2012-05-02 Thread Alan Reiner
I want to follow up on BIP 21 (URI scheme), which I have recently 
implemented in Armory and I have become a huge fan of it.  But I've got 
a couple gripes:


*(1) *What is the status & plans for supporting "bitcoin:" URIs in the 
Satoshi client?  My understanding is that it currently creates URIs, but 
does *not* register itself with the OS to handle such links.  Is this 
accurate?  This seems like a very high-value feature, and I'd recommend 
that we consider it a priority -- I can't think of any other upgrade 
that can improve usability so dramatically on the desktop.


After implementing it all in Armory, I wrote up a walk-thru 
 
recounting how I did the OS-registration in Windows and gnome-based *nix 
systems.  Perhaps it can give the Bitcoin-Qt devs a jumpstart on getting 
it implemented.  (and then I can get feedback about doing for generic 
Linux and Mac/OSX)



*(2) *I need to understand better what the intentions were behind 
"label=" and "message=".  The way I understand it is that Bitcoin-Qt 
uses and stores only address-labels, and no other transactional info is 
stored in the wallet.  As such, the "message=" field would be displayed 
to the user when a "bitcoin:" link is clicked, but that message wouldn't 
be saved anywhere.


However, I think, especially if a new wallet format is in the works, 
that both should be supported:  "Address Labels" *and *"Transaction 
Labels".  The real difference is that merchants can include things 
Order#, purchase information, etc, in the "message" field, and then put 
only their business name in the "label" field.  This means that when the 
user is looking at their address book, they see just the owners of the 
addresses.  When they look at the transaction ledger/history, they see a 
full list of everything they purchased, prices, contact info, etc.   The 
distinction is much more important for persistent addresses, but still 
important.


This is exactly how I did it in Armory, but if Bitcoin-Qt won't do it 
that way, I should be promoting all important information be jammed into 
the "label" field.


*(3) *How are the other clients implementing this?  Do you make any 
distinction between "label" and "message"?


-Alan
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-05-02 Thread Jeff Garzik
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki  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.
jgar...@exmulti.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-05-02 Thread 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

jim...@fastmail.co.uk
--
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

2012-05-02 Thread Gary Rowe
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  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...
>
>
--
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

2012-05-02 Thread 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...


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

2012-05-02 Thread Alan Reiner
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  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 
> 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  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 
> >To: grarpamp 
> >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  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.
> >jgar...@exmulti.com
> >
>
> >--
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >___

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

2012-05-02 Thread Gary Rowe
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  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 
> 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  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 
> >To: grarpamp 
> >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  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.
> >jgar...@exmulti.com
> >
>
> >--
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >___
> >Bitcoin-development mailing list
> >Bitcoin-development@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >--
> >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/
> >___

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

2012-05-02 Thread 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 
To: "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  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 
>To: grarpamp 
>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  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.
>jgar...@exmulti.com
>
>--
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>--
>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 inclu

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

2012-05-02 Thread Alan Reiner
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  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  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 
>> To: grarpamp 
>> 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  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.
>> jgar...@exmulti.com
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> --
>> 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/
> ___

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

2012-05-02 Thread Gary Rowe
Or we could just point everyone here:
http://lovebitcoins.org/getStarted.html

:-)

On 2 May 2012 20:40, Raphael NICOLLE  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  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 
>> To: grarpamp 
>> 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  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.
>> jgar...@exmulti.com
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> --
>> 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
>
>
--
Live Security Virtu

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

2012-05-02 Thread Raphael NICOLLE
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 > 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 mailto:jgar...@exmulti.com>>
To: grarpamp mailto:grarp...@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 mailto:grarp...@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.
jgar...@exmulti.com 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest in
malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/bitcoin-development



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

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

2012-05-02 Thread Alan Reiner
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 , or My
Desktop "  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  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 
> To: grarpamp 
> 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  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.
> jgar...@exmulti.com
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> 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-developm

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

2012-05-02 Thread Gary Rowe
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  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 
> To: grarpamp 
> 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  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.
> jgar...@exmulti.com
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> 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

2012-05-02 Thread 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 
To: grarpamp 
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  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.
jgar...@exmulti.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-05-02 Thread Jeff Garzik
On Wed, May 2, 2012 at 12:58 PM, grarpamp  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.
jgar...@exmulti.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-05-02 Thread 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.

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

2012-05-02 Thread 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?

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

2012-05-02 Thread 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"

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

2012-05-02 Thread 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 :)

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

2012-05-02 Thread Alan Reiner
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  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.
>
--
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

2012-05-02 Thread Mike Hearn
>
> 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.
--
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

2012-05-02 Thread 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.

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

2012-05-02 Thread Mike Hearn
>
> 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.
--
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

2012-05-02 Thread 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.

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

2012-05-02 Thread 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.

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

2012-05-02 Thread Mike Hearn
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 

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 

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 

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 

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