Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Modern Java versions let you bundle the app with a stripped down JVM. I don't know if Jim does that, but I think it's an obvious step towards making MultiBit friendlier and easier to use. BTW I believe most secure browsers (Chrome, Firefox) have banned the applet plugin or severely restrained it anyway. So even if you install the JVM and plugin together there is not an issue. On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: Java (Applet) security is indeed abysmal but lets compare apples to apples. With an applet some random guy with a website makes up some Java code and your browser automatically executes it. With Multibit you're only executing highly trusted code (so trusted that it handles your money). There has almost never been a Java exploit against secure trusted code. The idea of discouraging use of java apps just because people would be tricked into activating the browser plugin when installing the JVM is probably valid but Multibit is the only reasonably complete client outside of bitcoinqt and I think client diversity is more important than stamping out java. Thanks, Caleb On 07/08/2013 08:22 PM, Robert Backhaus wrote: But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. On 1 July 2013 02:39, Gary Rowe g.r...@froot.co.uk mailto: g.r...@froot.co.uk wrote: I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim jim...@fastmail.co.uk mailto: jim...@fastmail.co.uk wrote: Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com http://bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto: Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto: Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
on 07/09/2013 06:56 AM Jim said the following: + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Tue, Jul 9, 2013 at 10:00 AM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 06:56 AM Jim said the following: + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. Indeed. There is no reason to worry about download bandwidth these days, for open source software downloads. Move the downloads to a site where such worries do not exist. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
For those interested in these things the multibit.org server is a dedicated server hosted by the German company http://www.server4you.net. It is physically located in the delightful city of Strasbourg, just on the French side of the French German border. On Tue, Jul 9, 2013, at 03:28 PM, Mike Hearn wrote: SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Jul 9, 2013 at 10:00 AM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 06:56 AM Jim said the following: + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. Indeed. There is no reason to worry about download bandwidth these days, for open source software downloads. Move the downloads to a site where such worries do not exist. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
on 07/09/2013 10:28 AM Mike Hearn said the following: SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. the point was just that if need be free capacity is available without having to throw money at it. until there's no need, doesn't matter. also hackability (and ui) should be irrelevant for the autoupdate process (which i presume will do all kinds of checksum and sig verification). and it's likely the autoupdates that will create very lumpy download demand. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
That's true - we could serve new users off our own servers and auto updates off SF.net mirrors, potentially. On Tue, Jul 9, 2013 at 4:57 PM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 10:28 AM Mike Hearn said the following: SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. the point was just that if need be free capacity is available without having to throw money at it. until there's no need, doesn't matter. also hackability (and ui) should be irrelevant for the autoupdate process (which i presume will do all kinds of checksum and sig verification). and it's likely the autoupdates that will create very lumpy download demand. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues. Mike Hearn m...@plan99.net wrote: That's true - we could serve new users off our own servers and auto updates off SF.net mirrors, potentially. On Tue, Jul 9, 2013 at 4:57 PM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 10:28 AM Mike Hearn said the following: SourceForge has a horrible UI and blocks some countries. It also exposes us to a large and potentially hackable mirror network. Whilst we're not bandwidth constrained on our own servers, let's try and keep using them. the point was just that if need be free capacity is available without having to throw money at it. until there's no need, doesn't matter. also hackability (and ui) should be irrelevant for the autoupdate process (which i presume will do all kinds of checksum and sig verification). and it's likely the autoupdates that will create very lumpy download demand. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Not any more than sourceforge or github.. None of these solutions are replacements, but rather only supplements to self hosted files. Jeff Garzik jgar...@bitpay.com wrote: On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson n...@mynicknet.com wrote: What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues. Cloudflare is rapidly becoming a bitcoin community SPOF. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
That's good to know. Still, at the moment we'd need to dramatically increase the download size and increase Bitcoin usage by 10x to hit our limits. It'd be a good problem to have. On Tue, Jul 9, 2013 at 5:51 PM, Johnathan Corgan johnat...@corganlabs.comwrote: On 07/09/2013 08:32 AM, Nick Simpson wrote: What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues. By way of endorsement, at the GNU Radio Project we switched to CloudFlare's free service tier a few months ago. We host on AWS EC2 our own web servers, downloads, and git repositories. CloudFlare has reduced our bandwidth bill by about 50%, with very little pain. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
It particulary worries me that a lot of sites hand over their SSL private keys to Cloudflare, and they are located in prism land. Cloudflare is rapidly becoming a bitcoin community SPOF. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. On 1 July 2013 02:39, Gary Rowe g.r...@froot.co.uk wrote: I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim jim...@fastmail.co.uk wrote: Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Java (Applet) security is indeed abysmal but lets compare apples to apples. With an applet some random guy with a website makes up some Java code and your browser automatically executes it. With Multibit you're only executing highly trusted code (so trusted that it handles your money). There has almost never been a Java exploit against secure trusted code. The idea of discouraging use of java apps just because people would be tricked into activating the browser plugin when installing the JVM is probably valid but Multibit is the only reasonably complete client outside of bitcoinqt and I think client diversity is more important than stamping out java. Thanks, Caleb On 07/08/2013 08:22 PM, Robert Backhaus wrote: But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. On 1 July 2013 02:39, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim jim...@fastmail.co.uk mailto:jim...@fastmail.co.uk wrote: Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com http://bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim jim...@fastmail.co.uk wrote: Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Arguments in favor of retaining Bitcoin-Qt/bitcoind default: * More field experience, code review and testing on desktop than others I'm hoping that if we start promoting alternative wallets their dev communities will get larger. Most bitcoinj code is peer reviewed, but not to the same extent that Bitcoin-Qt is. We're obviously not going to stop promoting Bitcoin-Qt as well. I think the distinction should be: * Want to get started fast? Grab MultiBit and you'll be under way in a couple of minutes. * Want to help out the Bitcoin network? Leave your computer switched on all the time and run Bitcoin-Qt instead. It will donate some of your computers resources to running the Bitcoin system. The MultiBit interface is OK but all desktop wallets could use some love from a friendly UI designer. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn m...@plan99.net wrote: I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), Yeah. That's not the primary privacy issue with bitcoinj though. I'm much, much more concerned about leaks via the block chain than the network layer. Especially as Tor is basically a giant man in the middle, without any kind of authentication you can easily end up connected to a sybil network without any idea. I'd be surprised if Tor usage was very high amongst Bitcoin users. Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find true transaction origins. Which reminds me, again, we need node-to-node connections to be encrypted to at least protect against network-wide passive sniffiing. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. It's not a library limitation anyway, it's a case of how best to present information to a user who is not familiar with how Bitcoin works. Safe and Not safe is still a rather misleading distinction given the general absence of double spends against mempool transactions, but it's still a lot more meaningful than 2 confirms For what it is worth I ran a double-spend generator a month or so ago against the replace-by-fee node that Peter setup and I found that a small number of the double-spends did in fact appear to be mined under replace-by-fee rules. Specifically the generator would create a transaction from confirmed inputs, wait 60-180 seconds (randomized) to allow for full propagation, and then create a double-spend if the transaction hadn't already been mined. The transactions were randomized to look like normal traffic, including occasional bets to Satoshidice and similar for fun. (for the record the script had no way of knowing if a bet won and would happily attempt to double-spend wins) Fees for the replacement were power-law distributed IIRC, with some occasionally set to be quite hefty. Though possibly just an artifact of unusually slow transaction propagation it appeared that about 0.25% of hashing power was following replace-by-fee rules. (not including transactions involving gambling, I know Eligius and perhaps others block such transactions from their mempools making double-spends easy to accomplish by including Satoshidice outputs) I'm actually surprised by that figure myself given Peter Todd and I haven't made a serious attempt yet to get miners to use replace-by-fee rules. An interesting experiment would be to advertise that money is being given away by such a tx generator in the mining forum, although I would prefer to see solid mempool support for the scorched-earth double-spend countermeasure first; Peter sounds like he has some great ideas there, although as usual I am seeing very little in the way of code. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= =QtjI -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
I suspect what you saw is mining nodes restarting and clearing their mempools out rather than an explicit policy of replace by fee. On Fri, Jun 28, 2013 at 12:09 PM, John Dillon john.dillon...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn m...@plan99.net wrote: I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), Yeah. That's not the primary privacy issue with bitcoinj though. I'm much, much more concerned about leaks via the block chain than the network layer. Especially as Tor is basically a giant man in the middle, without any kind of authentication you can easily end up connected to a sybil network without any idea. I'd be surprised if Tor usage was very high amongst Bitcoin users. Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find true transaction origins. Which reminds me, again, we need node-to-node connections to be encrypted to at least protect against network-wide passive sniffiing. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. It's not a library limitation anyway, it's a case of how best to present information to a user who is not familiar with how Bitcoin works. Safe and Not safe is still a rather misleading distinction given the general absence of double spends against mempool transactions, but it's still a lot more meaningful than 2 confirms For what it is worth I ran a double-spend generator a month or so ago against the replace-by-fee node that Peter setup and I found that a small number of the double-spends did in fact appear to be mined under replace-by-fee rules. Specifically the generator would create a transaction from confirmed inputs, wait 60-180 seconds (randomized) to allow for full propagation, and then create a double-spend if the transaction hadn't already been mined. The transactions were randomized to look like normal traffic, including occasional bets to Satoshidice and similar for fun. (for the record the script had no way of knowing if a bet won and would happily attempt to double-spend wins) Fees for the replacement were power-law distributed IIRC, with some occasionally set to be quite hefty. Though possibly just an artifact of unusually slow transaction propagation it appeared that about 0.25% of hashing power was following replace-by-fee rules. (not including transactions involving gambling, I know Eligius and perhaps others block such transactions from their mempools making double-spends easy to accomplish by including Satoshidice outputs) I'm actually surprised by that figure myself given Peter Todd and I haven't made a serious attempt yet to get miners to use replace-by-fee rules. An interesting experiment would be to advertise that money is being given away by such a tx generator in the mining forum, although I would prefer to see solid mempool support for the scorched-earth double-spend countermeasure first; Peter sounds like he has some great ideas there, although as usual I am seeing very little in the way of code. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= =QtjI -END PGP SIGNATURE-
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. Possible non-validation data that can be usefully propagated: 1) Block headers. 2) *Confirmed* transactions linked to an aformentioned blockheader. 3) Proof-of-work/sacrifice limited P2P messages, for instance to co-ordinate trust-free-mixes or act as a communication channel for micropayment channels. 4) With UTXO existance proof support propagate transactions accompanied by proofs that all inputs exist. This would also allow for implementation of Peter's low-bandwidth decentralized P2Pool proposal. 5) UTXO fraud proofs. (one day) Strictly speaking #2 doesn't even need the protocol to be changed actually as it can be handled entirely within the existing INV/getdata mechanism. Sure someone could throw away a lot of hashing power and get an invalid block propagated, but really so what? SPV nodes should always take confirmations with a grain of salt anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWx8AAoJEEWCsU4mNhiPlTkIAJKzFsT65o6LoU70hbaBsu3g aBdjYZSCnJ9+qWI2tqqUBedq2etbt71hAfWNnTXvFus+0iVB1HWJClW155319vuH Xi1m9G3O0NzX1d+cssMPxFBHsl4Rz6XYICrYyVEe2X554Zawdg6I53+1INHRfsBT 1vmq5Bxgopt0Tk9Vf8HNdRt/IXZJaPYm1PEzJHFppuOvl5+Fpypy3t/QXdsP8puP LnRdL7Bxfu3BSWrSRZo7l5Fpww3Y/vdNYCL4jDD/ME+36wi4CUM3psL8lsk81lB4 3t/ytF4y/adT/dEEtMj7BGWS0TIMMH0NyeCjqBdStiQsVfoowLCVfpuDzouZ6yY= =TI1m -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
There are already descriptions as you describe on: http://bitcoin.org/en/choose-your-wallet. If you hover over any of the wallet icons you get a description and a link. People being people, we find in practice that the very first wallet link on the page is what the majority of new users click. On Fri, Jun 28, 2013, at 09:37 PM, Bill Hees wrote: There are good, valid arguments in support of promoting both the reference client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not outline these arguments on bitcoin.org and provide links to each; or even links to a variety of alternative wallet solutions alongside descriptions of their respective benefits and drawbacks? Is there an advantage to having a singular recommended client? On Fri, Jun 28, 2013 at 1:35 PM, Bill Hees billh...@gmail.com wrote: There are good, valid arguments in support of promoting both the reference client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not outline these arguments on bitcoin.org and provide links to each; or even links to a variety of alternative wallet solutions alongside descriptions of their respective benefits and drawbacks? Is there an advantage to having a singular recommended client? On Fri, Jun 28, 2013 at 7:24 AM, Gavin Andresen gavinandre...@gmail.comwrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Hello Everybody, Over the last few months we have been steadily adding functionality to MultiBit including: + encrypted wallets + sign and verify message + stability improvements and bug fixes. As a result of these efforts I think MultiBit is now suitable for the entry level Bitcoin user. I propose that we put MultiBit as the default desktop client on the bitcoin.org Choose your wallet page. I think a typical new user comes to bitcoin.org from a google search or a Bitcoin news article. We want them to peruse the bitcoin.org site and try out a wallet. They should be able to get MultiBit up and running in a tea break. Then perhaps they get a colleague to send them some bitcoin from an Android phone by zapping a QR code. We say: Welcome to the Bitcoin economy ! There is plenty MultiBit cannot do of course. However if in the first ten minutes we get the new user interested there is a good chance they will go on to explore other Bitcoin wallets and solutions. Let me know if you think this is a good idea (or not!) and if you have any questions. Jim https://multibit.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 1:10 PM, Jim jim...@fastmail.co.uk wrote: Hello Everybody, Over the last few months we have been steadily adding functionality to MultiBit including: + encrypted wallets + sign and verify message + stability improvements and bug fixes. As a result of these efforts I think MultiBit is now suitable for the entry level Bitcoin user. I propose that we put MultiBit as the default desktop client on the bitcoin.org Choose your wallet page. I think a typical new user comes to bitcoin.org from a google search or a Bitcoin news article. We want them to peruse the bitcoin.org site and try out a wallet. They should be able to get MultiBit up and running in a tea break. Then perhaps they get a colleague to send them some bitcoin from an Android phone by zapping a QR code. This is definitely a great discussion to have. Here are some initial, unprioritized thoughts. As an engineer, there is never a clear answer, but a balance of costs and benefits. Arguments in favor of moving away from Bitcoin-Qt/bitcoind for wallet services: * Bitcoin-Qt is admittedly a very simple wallet. I see it's core strengths more as a P2P router for the public blockchain data. * Wallet feature innovation moves more slowly than Armory/bitcoinj/blockchain.info. * Requires the full blockchain, which is resource-intensive versus SPV. Arguments in favor of retaining Bitcoin-Qt/bitcoind default: * More field experience, code review and testing on desktop than others * Very real possibility of an overall net reduction of full nodes on P2P network Arguments in favor of multibit default: * Good user interface, perhaps more friendly for entry level users as you describe * Based on bitcoinj, which has field experience and a very large installed base thanks to Bitcoin Wallet/Schildbach Arguments against multibit default: * Less testing, field experience on desktop I'm sure others can come up with a few more. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Hi guys, This would be a big step forward. Anecdotally I can report that 5% of * non-nerds* who don't abandon Bitcoin after waiting for the initial blockchain download and *ongoing* sync on every restart, end up using blockchain.info simply because it just works and works on their iPads iPhones. Conversely, all the serious nerds end up using Armory and/or Brainwallets for ultimate control. On Thu, Jun 27, 2013 at 10:56 AM, Gregory Maxwell gmaxw...@gmail.comwrote: On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Alex Kravets http://www.linkedin.com/in/akravets def redPill = ' Scala http://www.scala-lang.org/ [[ brutal honesty http://goo.gl/vwydt is the best policy ]] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? I'm sure others can come up with a few more. Possibly against: Does MultiBit still promote Bitcoin misunderstandings with misinformation like from addresses? (my apologies if I am remembering a different client) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
RE: 141.101.113.245 http://whois.domaintools.com/141.101.113.245 gives it as CloudFlare - I suspect it is protecting Mt Gox when we make our get for currency ticker info. On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
I missed Greg's point on confirmations. It is definitely a challenge to explain/ visualize both: + has the transaction propagated the network ? and + it it confirmed/ buried in a block ? when those words probably don't mean much to the intended audience. The transaction status icons I *think* do it (explained here: https://multibit.org/en/help/v0.5/help_transactions.html). It basically boils down to: 1) triangle or square : bad. 2) filling circle : good 3) tick mark : great. On Thu, Jun 27, 2013, at 08:40 PM, Jim wrote: RE: 141.101.113.245 http://whois.domaintools.com/141.101.113.245 gives it as CloudFlare - I suspect it is protecting Mt Gox when we make our get for currency ticker info. On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote: A few replies, in order of point raised: Jeff: Arguments against multibit default: * Less testing, field experience on desktop Yes this is true - downloads of multibit have typically been around 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that the bitcoinj networking/ object model is also used by Andreas as you note. Greg: I think Mike has squashed the deadlocking problems with reentrant locks (primarily in the Wallet). I haven't seen one in at least a month. We discussed proxy support on the bitcoinj mailing list a while ago and at the time the stumbling block was the Java library used for the networking (Netty) did not support it. Mike or Miron would know better than I if this is still the case. Change address behaviour will improve significantly when HD wallet support goes into multibit/ bitcoinj (I am hoping to get my bit done over the summer). Matija Mazi has been working on a Java impl of HD wallets so it is coming down the pipe but there is a lot to do yet. Connections out from MultiBit are: + 4 bitcoind nodes on port 8333 + multibit.org (188.138.113.201) for help, current version info (and probably more in future) + the currency ticker will make HTTP gets to the source of whichever exchange(s) you have set up e.g MtGox, CampBX. This calls should disappear if you switch the currency conversion and ticker off. I think that is all the connections out I make. Mainly due to the exchanges abruptly changing their APIs and breaking things we are planning to put in intermediate Exchange Data Provider servers. Tim Molter is working on this in his XChange project. That will enable us to patch the server when things change and the multibits in the field won't be affected. There will probably be a couple of these initially for redundancy. Alex: Yes I think most users migrate to blockchain.info or, more recently coinbase.com. They are both good wallets but I'd like to keep Bitcoin as P2P as possible. Luke-Jr I think you are right here on the number of full nodes versus SPV nodes. I don't think we even know yet what are the working ratios of full nodes to SPV nodes. I haven't seen anybody do any analysis on this. I doubt multibit will ever participate in the Bitcoin network other than as an SPV client. All the optimisation is to reduce data traffic - it is effectively a mobile wallet that happens to live on a desktop. It is not really intended to be more than a wallet for regular people to store and spend their bitcoin. In English the nomenclature for direction of the transactions is: Sent to and Received with. To be honest I haven't transliterated the localisation files to check other language packs but the localisers are pretty good in my experience. On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On 06/27/2013 01:56 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), If I were a Bitcoin dev, I would not want to talk about anonymity or TOR because that's likely to attract people with paranoid dilutions and they're really terrible users to support :) Also yay for promoting fast, easy to use clients for casual users! Thanks, Caleb that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
