* [Bitcoin-development] new bitcoin.org clients page @ 2012-04-30 17:50 Amir Taaki 2012-04-30 18:23 ` Alan Reiner 2012-05-02 23:04 ` Jeff Garzik 0 siblings, 2 replies; 34+ messages in thread From: Amir Taaki @ 2012-04-30 17:50 UTC (permalink / raw) To: bitcoin-development Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-04-30 17:50 [Bitcoin-development] new bitcoin.org clients page Amir Taaki @ 2012-04-30 18:23 ` Alan Reiner 2012-04-30 18:31 ` Amir Taaki 2012-05-02 23:04 ` Jeff Garzik 1 sibling, 1 reply; 34+ messages in thread From: Alan Reiner @ 2012-04-30 18:23 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-04-30 18:23 ` Alan Reiner @ 2012-04-30 18:31 ` Amir Taaki 2012-04-30 19:51 ` Alan Reiner 0 siblings, 1 reply; 34+ messages in thread From: Amir Taaki @ 2012-04-30 18:31 UTC (permalink / raw) To: bitcoin-development Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your browser. Also about the descriptions: yeah I know. I think it's better to put this up first and then have everyone submit their own descriptions and screenshots. Otherwise it'll be a nightmare to coordinate until everything is perfect. I did message you on IRC today but maybe you were offline. I didn't copy paste the Armory description from the website because it really sounds too spammy like a sales pitch. Here I was trying to give an even handed balanced overview of all the clients. For each client I was trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. MultiBit is ease of use. ________________________________ From: Alan Reiner <etotheipi@gmail•com> To: Amir Taaki <zgenjix@yahoo•com> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Monday, April 30, 2012 7:23 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page Hey, looks good! I'm glad to see them sorted alphabetically :) A couple comments: I don't think the entries for "wallet security" and "backups" accurately describe Armory. Wallet Security should say "Encrypt/Offline" or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like "One-time Printable" if it fits within the box. Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the "reference" client, and I think it's relevant that it is the "de-facto" client for the majority of users, and the one with the most quality control and stability. -Alan On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki <zgenjix@yahoo•com> wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-04-30 18:31 ` Amir Taaki @ 2012-04-30 19:51 ` Alan Reiner 2012-05-02 13:22 ` Mike Hearn 0 siblings, 1 reply; 34+ messages in thread From: Alan Reiner @ 2012-04-30 19:51 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-04-30 19:51 ` Alan Reiner @ 2012-05-02 13:22 ` Mike Hearn 2012-05-02 13:30 ` Gregory Maxwell ` (4 more replies) 0 siblings, 5 replies; 34+ messages in thread From: Mike Hearn @ 2012-05-02 13:22 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:22 ` Mike Hearn @ 2012-05-02 13:30 ` Gregory Maxwell 2012-05-02 13:32 ` Mike Hearn 2012-05-02 13:31 ` Luke-Jr ` (3 subsequent siblings) 4 siblings, 1 reply; 34+ messages in thread From: Gregory Maxwell @ 2012-05-02 13:30 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:30 ` Gregory Maxwell @ 2012-05-02 13:32 ` Mike Hearn 0 siblings, 0 replies; 34+ messages in thread From: Mike Hearn @ 2012-05-02 13:32 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:22 ` Mike Hearn 2012-05-02 13:30 ` Gregory Maxwell @ 2012-05-02 13:31 ` Luke-Jr 2012-05-02 16:21 ` grarpamp 2012-05-02 13:38 ` Gregory Maxwell ` (2 subsequent siblings) 4 siblings, 1 reply; 34+ messages in thread From: Luke-Jr @ 2012-05-02 13:31 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:31 ` Luke-Jr @ 2012-05-02 16:21 ` grarpamp 2012-05-02 16:30 ` Luke-Jr 0 siblings, 1 reply; 34+ messages in thread From: grarpamp @ 2012-05-02 16:21 UTC (permalink / raw) To: bitcoin-development > 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 :) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 16:21 ` grarpamp @ 2012-05-02 16:30 ` Luke-Jr 2012-05-02 16:58 ` grarpamp 0 siblings, 1 reply; 34+ messages in thread From: Luke-Jr @ 2012-05-02 16:30 UTC (permalink / raw) To: bitcoin-development 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" ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 16:30 ` Luke-Jr @ 2012-05-02 16:58 ` grarpamp 2012-05-02 18:29 ` Jeff Garzik 0 siblings, 1 reply; 34+ messages in thread From: grarpamp @ 2012-05-02 16:58 UTC (permalink / raw) To: bitcoin-development > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 16:58 ` grarpamp @ 2012-05-02 18:29 ` Jeff Garzik 2012-05-02 19:25 ` Amir Taaki 2012-05-03 9:06 ` grarpamp 0 siblings, 2 replies; 34+ messages in thread From: Jeff Garzik @ 2012-05-02 18:29 UTC (permalink / raw) To: grarpamp; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 18:29 ` Jeff Garzik @ 2012-05-02 19:25 ` Amir Taaki 2012-05-02 19:34 ` Gary Rowe 2012-05-02 19:35 ` Alan Reiner 2012-05-03 9:06 ` grarpamp 1 sibling, 2 replies; 34+ messages in thread From: Amir Taaki @ 2012-05-02 19:25 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:25 ` Amir Taaki @ 2012-05-02 19:34 ` Gary Rowe 2012-05-02 19:40 ` Raphael NICOLLE ` (3 more replies) 2012-05-02 19:35 ` Alan Reiner 1 sibling, 4 replies; 34+ messages in thread From: Gary Rowe @ 2012-05-02 19:34 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:34 ` Gary Rowe @ 2012-05-02 19:40 ` Raphael NICOLLE 2012-05-02 19:42 ` Gary Rowe 2012-05-02 19:43 ` Alan Reiner ` (2 subsequent siblings) 3 siblings, 1 reply; 34+ messages in thread From: Raphael NICOLLE @ 2012-05-02 19:40 UTC (permalink / raw) To: Gary Rowe; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:40 ` Raphael NICOLLE @ 2012-05-02 19:42 ` Gary Rowe 0 siblings, 0 replies; 34+ messages in thread From: Gary Rowe @ 2012-05-02 19:42 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:34 ` Gary Rowe 2012-05-02 19:40 ` Raphael NICOLLE @ 2012-05-02 19:43 ` Alan Reiner 2012-05-02 19:43 ` Amir Taaki 2012-05-02 20:25 ` Luke-Jr 3 siblings, 0 replies; 34+ messages in thread From: Alan Reiner @ 2012-05-02 19:43 UTC (permalink / raw) To: Gary Rowe; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:34 ` Gary Rowe 2012-05-02 19:40 ` Raphael NICOLLE 2012-05-02 19:43 ` Alan Reiner @ 2012-05-02 19:43 ` Amir Taaki 2012-05-02 19:46 ` Gary Rowe 2012-05-02 19:56 ` Alan Reiner 2012-05-02 20:25 ` Luke-Jr 3 siblings, 2 replies; 34+ messages in thread From: Amir Taaki @ 2012-05-02 19:43 UTC (permalink / raw) To: bitcoin-development This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable). If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details: http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: You suggest creating something new for your hackerspace, like a bikeshed. But now all anyone will discuss is its colour. No bikeshed will be built. Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum. ________________________________ From: Gary Rowe <g.rowe@froot•co.uk> To: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net> Sent: Wednesday, May 2, 2012 8:34 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page How about keeping it simple? Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/ Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/ Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en On 2 May 2012 20:25, Amir Taaki <zgenjix@yahoo•com> wrote: This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. > >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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:43 ` Amir Taaki @ 2012-05-02 19:46 ` Gary Rowe 2012-05-02 19:56 ` Alan Reiner 1 sibling, 0 replies; 34+ messages in thread From: Gary Rowe @ 2012-05-02 19:46 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:43 ` Amir Taaki 2012-05-02 19:46 ` Gary Rowe @ 2012-05-02 19:56 ` Alan Reiner 1 sibling, 0 replies; 34+ messages in thread From: Alan Reiner @ 2012-05-02 19:56 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:34 ` Gary Rowe ` (2 preceding siblings ...) 2012-05-02 19:43 ` Amir Taaki @ 2012-05-02 20:25 ` Luke-Jr 2012-05-02 20:39 ` Gary Rowe 3 siblings, 1 reply; 34+ messages in thread From: Luke-Jr @ 2012-05-02 20:25 UTC (permalink / raw) To: bitcoin-development 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... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 20:25 ` Luke-Jr @ 2012-05-02 20:39 ` Gary Rowe 0 siblings, 0 replies; 34+ messages in thread From: Gary Rowe @ 2012-05-02 20:39 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 19:25 ` Amir Taaki 2012-05-02 19:34 ` Gary Rowe @ 2012-05-02 19:35 ` Alan Reiner 1 sibling, 0 replies; 34+ messages in thread From: Alan Reiner @ 2012-05-02 19:35 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 18:29 ` Jeff Garzik 2012-05-02 19:25 ` Amir Taaki @ 2012-05-03 9:06 ` grarpamp 1 sibling, 0 replies; 34+ messages in thread From: grarpamp @ 2012-05-03 9:06 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development > "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 :) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:22 ` Mike Hearn 2012-05-02 13:30 ` Gregory Maxwell 2012-05-02 13:31 ` Luke-Jr @ 2012-05-02 13:38 ` Gregory Maxwell 2012-05-02 13:42 ` Mike Hearn 2012-05-02 16:53 ` grarpamp 2012-05-03 7:28 ` Andreas Schildbach 4 siblings, 1 reply; 34+ messages in thread From: Gregory Maxwell @ 2012-05-02 13:38 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:38 ` Gregory Maxwell @ 2012-05-02 13:42 ` Mike Hearn 2012-05-02 15:01 ` Alan Reiner 0 siblings, 1 reply; 34+ messages in thread From: Mike Hearn @ 2012-05-02 13:42 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:42 ` Mike Hearn @ 2012-05-02 15:01 ` Alan Reiner 0 siblings, 0 replies; 34+ messages in thread From: Alan Reiner @ 2012-05-02 15:01 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:22 ` Mike Hearn ` (2 preceding siblings ...) 2012-05-02 13:38 ` Gregory Maxwell @ 2012-05-02 16:53 ` grarpamp 2012-05-03 7:28 ` Andreas Schildbach 4 siblings, 0 replies; 34+ messages in thread From: grarpamp @ 2012-05-02 16:53 UTC (permalink / raw) To: bitcoin-development > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-02 13:22 ` Mike Hearn ` (3 preceding siblings ...) 2012-05-02 16:53 ` grarpamp @ 2012-05-03 7:28 ` Andreas Schildbach 2012-05-03 9:24 ` Jorge Timón 4 siblings, 1 reply; 34+ messages in thread From: Andreas Schildbach @ 2012-05-03 7:28 UTC (permalink / raw) To: bitcoin-development 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/ -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-03 7:28 ` Andreas Schildbach @ 2012-05-03 9:24 ` Jorge Timón 2012-05-03 9:53 ` Andreas Schildbach 0 siblings, 1 reply; 34+ messages in thread From: Jorge Timón @ 2012-05-03 9:24 UTC (permalink / raw) Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-03 9:24 ` Jorge Timón @ 2012-05-03 9:53 ` Andreas Schildbach 2012-05-03 10:25 ` Jorge Timón 0 siblings, 1 reply; 34+ messages in thread From: Andreas Schildbach @ 2012-05-03 9:53 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-05-03 9:53 ` Andreas Schildbach @ 2012-05-03 10:25 ` Jorge Timón 0 siblings, 0 replies; 34+ messages in thread From: Jorge Timón @ 2012-05-03 10:25 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page 2012-04-30 17:50 [Bitcoin-development] new bitcoin.org clients page Amir Taaki 2012-04-30 18:23 ` Alan Reiner @ 2012-05-02 23:04 ` Jeff Garzik 1 sibling, 0 replies; 34+ messages in thread From: Jeff Garzik @ 2012-05-02 23:04 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Bitcoin-development] new bitcoin.org clients page @ 2012-05-02 20:41 Jim 0 siblings, 0 replies; 34+ messages in thread From: Jim @ 2012-05-02 20:41 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2012-05-03 10:25 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-30 17:50 [Bitcoin-development] new bitcoin.org clients page Amir Taaki 2012-04-30 18:23 ` Alan Reiner 2012-04-30 18:31 ` Amir Taaki 2012-04-30 19:51 ` Alan Reiner 2012-05-02 13:22 ` Mike Hearn 2012-05-02 13:30 ` Gregory Maxwell 2012-05-02 13:32 ` Mike Hearn 2012-05-02 13:31 ` Luke-Jr 2012-05-02 16:21 ` grarpamp 2012-05-02 16:30 ` Luke-Jr 2012-05-02 16:58 ` grarpamp 2012-05-02 18:29 ` Jeff Garzik 2012-05-02 19:25 ` Amir Taaki 2012-05-02 19:34 ` Gary Rowe 2012-05-02 19:40 ` Raphael NICOLLE 2012-05-02 19:42 ` Gary Rowe 2012-05-02 19:43 ` Alan Reiner 2012-05-02 19:43 ` Amir Taaki 2012-05-02 19:46 ` Gary Rowe 2012-05-02 19:56 ` Alan Reiner 2012-05-02 20:25 ` Luke-Jr 2012-05-02 20:39 ` Gary Rowe 2012-05-02 19:35 ` Alan Reiner 2012-05-03 9:06 ` grarpamp 2012-05-02 13:38 ` Gregory Maxwell 2012-05-02 13:42 ` Mike Hearn 2012-05-02 15:01 ` Alan Reiner 2012-05-02 16:53 ` grarpamp 2012-05-03 7:28 ` Andreas Schildbach 2012-05-03 9:24 ` Jorge Timón 2012-05-03 9:53 ` Andreas Schildbach 2012-05-03 10:25 ` Jorge Timón 2012-05-02 23:04 ` Jeff Garzik 2012-05-02 20:41 Jim
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox