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.r...@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 <zgen...@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 <jgar...@exmulti.com> >To: grarpamp <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 <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.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
