Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-07-09 Thread Mike Hearn
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

2013-07-09 Thread Daniel F
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

2013-07-09 Thread Jeff Garzik
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

2013-07-09 Thread Jim
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

2013-07-09 Thread Daniel F
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

2013-07-09 Thread Mike Hearn
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

2013-07-09 Thread Nick Simpson
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

2013-07-09 Thread Nick Simpson
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

2013-07-09 Thread Johnathan Corgan
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



signature.asc
Description: OpenPGP digital signature
--
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

2013-07-09 Thread Mike Hearn
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

2013-07-09 Thread Andreas Petersson
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

2013-07-08 Thread Robert Backhaus
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

2013-07-08 Thread Caleb James DeLisle
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

2013-06-30 Thread Peter Todd
On Fri, Jun 28, 2013 at 10:09:16AM +, John Dillon wrote:
 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.

Agreed.

Speaking of, I may have missed it but as far as I can tell Bitmessage
doesn't encrypt node-to-node communications, a serious oversight. Any
attacker that can sniff a large fraction of the network, like the NSA,
can easily use this to track down the originating node of any message,
just like they can do with Bitcoin.

 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.

Ah! I had a feeling that might be you. Were you the person who was
creating the 1BTC fee transactions as well?

 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 just got an email from someone saying they had a few Avalons with that
patch installed actually; that was probably them.

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

Keep in mind it's not just the mempool that needs changing - the network
protocol semantics need to change too. For the scorched-earth strategy
to work you need nodes tell their peers about the total fees a
transaction has attached in addition tot he tx hash. Essentially you are
advertising to your peers what would right now be an orphan, and your
peers need to recursively get dependencies; I'm sure there's a bunch of
edge cases there that would be need to thought out carefully. It's
useful for a lot of things though, for instance when a zero-fee,
zero-priority tx is given to a merchant who now wants to tell miners to
mine it anyway due to a child tx.

What I'd recommend actually for the nearer term is just adding recursive
fee evaluation with a depth*breadth anti-DoS limit, adding the rpc and
GUI adjfee and canceltx commands, adding better wallet support for
conflicts, (someone is already workng on this) and adding a service bit
with preferential peering.

By preferential peering I mean you set aside a portion of your outgoing
peer slots for peers with certain bits set and only fill those slots
with those peers. In addition you can have DNS seeds return peers with
specified service bits set: x0003.v1.seed.petertodd.org
could be nodes with the first and second bits set. (we might want to
define the upper 8 service bits as a service bit version field so we can
redefine the other 56 in the far off future if required)

-- 
'peter'[:-1]@petertodd.org
00b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5


signature.asc
Description: Digital 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

2013-06-30 Thread Jim
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

2013-06-30 Thread Gary Rowe
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

2013-06-28 Thread Mike Hearn
 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

2013-06-28 Thread John Dillon
-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

2013-06-28 Thread Mike Hearn
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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn m...@plan99.net wrote:
 I suspect what you saw is mining nodes restarting and clearing their
 mempools out rather than an explicit policy of replace by fee.

Possibly, but it is a rather short window of opportunity and the mining node
would have to be connected directly, to Peter's replace-by-fee node. I also
took care to ensure transactions were only ever broadcast once. (I disabled the
wallet rebroadcast mechanism)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRzWYWAAoJEEWCsU4mNhiP3fIIAJLFxMnjI4BGRrNLsxs0hXp0
zDCgiZ6UnZa5JRcd/6KjV3hnPHwweGEjChGfrzY/Fxo4Pga1lQFlp8E8PaFUJq50
r6LTNJQLW50r5mFkZ6Mkh877WwX/OHBzkp8SqbbD7+dDBV7R9LqLYqLTHgObKxg1
V9UjGRJiMohW8HLdOzEXOz1ugoBCjR+vyQW5ZD2nZVcQlIhxSIgeC/M46oxMN7pE
Y5EepCQehNPuc1On7TtJ9LlmFJ6Dvsl6dqwKNWMi1lgBTiw7abdTJne2B/KeDyom
vhGuhmpMLGKKgJns3hne3yQM+Ivi3jLIHKejcoCm1JkSCdjw48XkyGd0V359M3w=
=qyyq
-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

2013-06-28 Thread John Dillon
-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

2013-06-28 Thread Gavin Andresen
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


Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-28 Thread Jim
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

2013-06-27 Thread Jim
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

2013-06-27 Thread Jeff Garzik
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

2013-06-27 Thread Gregory Maxwell
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

2013-06-27 Thread Alex Kravets
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

2013-06-27 Thread Luke-Jr
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

2013-06-27 Thread Gregory Maxwell
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

2013-06-27 Thread Jim
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

2013-06-27 Thread Jim
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

2013-06-27 Thread Jim
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

2013-06-27 Thread Caleb James DeLisle


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