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

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

[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

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

[Jeff Garzik]

On Thu, Jun 27, 2013 at 1:10 PM, Jim <jim618@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/

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

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

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

[Gregory Maxwell]

On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@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.

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

[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 <luke@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.org    Money, reinvented

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

[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 <luke@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.org    Money, 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.org    Money, reinvented

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

[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 <luke@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.org    Money, 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.org    Money, 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.org    Money, reinvented

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

[Alex Kravets]

[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]

Hi Jim,

On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618@fastmail.co.uk> wrote:

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

Guys, being a late comer/outsider (I got into bitcoin in early 2012), I can
tell you that this particular asylum is definitely run by its inmates.

What all the nerdy devs (and I am one so I know) seem unable to comprehend,
is that regular people out there don't wanna learn all this new stuff and
new terminology they simply have no attention span for it.

Simply channelling them to a decent client that

1. Just works (no blockchain downloads and no re-sync)
2. Allows to retain control of the private keys

Would be HUGE for mass adoption.

Old tired argument about "Bitcoin needs your nodes", so we'll channel you
to get bitcoin-qt client is both manipulative and unnecessary (there's
plenty of nodes and NAT'ed home nodes which don't mine are mostly useless
anyways)

P.S. coinbase.com is just another trust-me setup takes your coins in
exchange for IOUs, whereas blockchain.info does let you to retain control
of your private keys.

P.P.S. The reason why coinbase has gotten so big is precisely because they
don't trouble regular lawyers and doctors with all the nonsense but simply
give them a
"buy" and a "sell" button.





> 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 <luke@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.org    Money, 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
>



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

[-- Attachment #2: Type: text/html, Size: 5923 bytes --]

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

[Jeff Garzik]

On Thu, Jun 27, 2013 at 5:12 PM, Alex Kravets <kravets@gmail.com> wrote:
> What all the nerdy devs (and I am one so I know) seem unable to comprehend,
> is that regular people out there don't wanna learn all this new stuff and
> new terminology they simply have no attention span for it.

Bitcoin Wallet for Android is a decentralized client w/ network sync,
and it works just fine.  Fast, easy to use.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

[Alex Kravets]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Perhaps there should be two different sections on the web page.

Nerds  / Non-Nerds

With different recommendations for which clients to use.


On Thu, Jun 27, 2013 at 2:56 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> On Thu, Jun 27, 2013 at 5:12 PM, Alex Kravets <kravets@gmail.com> wrote:
> > What all the nerdy devs (and I am one so I know) seem unable to
> comprehend,
> > is that regular people out there don't wanna learn all this new stuff and
> > new terminology they simply have no attention span for it.
>
> Bitcoin Wallet for Android is a decentralized client w/ network sync,
> and it works just fine.  Fast, easy to use.
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>



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

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

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

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 4964 bytes --]

Many people that I have introduced Bitcoin to have balked at the massive
blockchain download. When I showed them MultiBit (and Bitcoin Wallet) they
breathed a sigh of relief and got on with it.

A currency lives or dies by network effects. If we can provide the average
low-tech user with a great client experience right from the word go then we
can win them over quickly. Once that is accomplished then more techie users
will likely go on to use a full node which will continue to strengthen the
network overall.



On 27 June 2013 22:12, Alex Kravets <kravets@gmail.com> wrote:

> Hi Jim,
>
> On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618@fastmail.co.uk> wrote:
>
>>
>> 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.
>>
>
> Guys, being a late comer/outsider (I got into bitcoin in early 2012), I
> can tell you that this particular asylum is definitely run by its inmates.
>
> What all the nerdy devs (and I am one so I know) seem unable to
> comprehend, is that regular people out there don't wanna learn all this new
> stuff and new terminology they simply have no attention span for it.
>
> Simply channelling them to a decent client that
>
> 1. Just works (no blockchain downloads and no re-sync)
> 2. Allows to retain control of the private keys
>
> Would be HUGE for mass adoption.
>
> Old tired argument about "Bitcoin needs your nodes", so we'll channel you
> to get bitcoin-qt client is both manipulative and unnecessary (there's
> plenty of nodes and NAT'ed home nodes which don't mine are mostly useless
> anyways)
>
> P.S. coinbase.com is just another trust-me setup takes your coins in
> exchange for IOUs, whereas blockchain.info does let you to retain control
> of your private keys.
>
> P.P.S. The reason why coinbase has gotten so big is precisely because they
> don't trouble regular lawyers and doctors with all the nonsense but simply
> give them a
> "buy" and a "sell" button.
>
>
>
>
>
>> 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 <luke@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.org    Money, 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
>>
>
>
>
> --
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 7597 bytes --]

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

[John Dillon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke@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-----

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

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

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

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

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

[Bill Hees]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

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 <billhees@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 <gavinandresen@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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2638 bytes --]

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

[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 <billhees@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 <gavinandresen@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.org    Money, reinvented

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

[Mike Hearn]

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

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

[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 <gavinandresen@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.org    Money, reinvented

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

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

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 <jim618@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 <gavinandresen@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.org    Money, 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
>

[-- Attachment #2: Type: text/html, Size: 4811 bytes --]

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

[Robert Backhaus]

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]

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.rowe@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 <jim618@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 <
>> gavinandresen@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.org    Money, 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
>
>

[-- Attachment #2: Type: text/html, Size: 6464 bytes --]

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

[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.rowe@froot.co.uk <mailto:g.rowe@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 <jim618@fastmail.co.uk <mailto:jim618@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 <gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
> 
> 
> 
>     ------------------------------------------------------------------------------
>     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
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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=48808831&iu=/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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 7539 bytes --]

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 <
calebdelisle@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.rowe@froot.co.uk <mailto:
> g.rowe@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 <jim618@fastmail.co.uk <mailto:
> jim618@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 <
> gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     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
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 11706 bytes --]

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

[Jim]

Yes I would like to bundle a JVM as it would simplify the user
experience.

There are a few downsides though:
+ all the build packaging will need redoing and retesting.
+ 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.

Currently there is no provision to update anything automatically.
I would like to start having Bitcoin signed files that MultiBit can
check
and update (initially the checkpoints file, I18N files - NOT code
at first because of the security implications). I think this needs to be 
in place before bundling a JVM so that users don't have to
keep redownloading it.

Having lists of all the artifacts signed and them having SHA256 hashes 
then makes it practical/ safe to start mirroring the code. I can see
each mirror crosschecking the others that the SHA256s are correct
for instance. This would increase the maximum number of 
downloads we could cope with.


On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> 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 <
> calebdelisle@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.rowe@froot.co.uk <mailto:
> > g.rowe@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 <jim618@fastmail.co.uk <mailto:
> > jim618@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 <
> > gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > >     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
> > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.org    Money, reinvented

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 11802 bytes --]

How many downloads/day do we see currently? I think you said it's on the
order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror
it if we need to.

The JavaFX packager is supposed to delete parts of the JVM that aren't
used. Is the 30-40mb figure based on using that tool or something else?
Note that you don't need to use the JFX widget toolkit to use the bundler
tool.

We could also invest in a copy of JET, which does native compilation down
to self contained Windows binaries. It might create smaller bundles. But,
it's a proprietary tool and I don't know how reproducible its outputs are.

For the auto update, is there an existing auto update framework that we can
modify to support threshold signed updates? I'm sure such a thing must
exist. The updates would download in the background and then the app can
just ask the user to restart it once the update is locally available, as
Chrome does.



On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail.co.uk> wrote:

> Yes I would like to bundle a JVM as it would simplify the user
> experience.
>
> There are a few downsides though:
> + all the build packaging will need redoing and retesting.
> + 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.
>
> Currently there is no provision to update anything automatically.
> I would like to start having Bitcoin signed files that MultiBit can
> check
> and update (initially the checkpoints file, I18N files - NOT code
> at first because of the security implications). I think this needs to be
> in place before bundling a JVM so that users don't have to
> keep redownloading it.
>
> Having lists of all the artifacts signed and them having SHA256 hashes
> then makes it practical/ safe to start mirroring the code. I can see
> each mirror crosschecking the others that the SHA256s are correct
> for instance. This would increase the maximum number of
> downloads we could cope with.
>
>
> On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> > 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 <
> > calebdelisle@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.rowe@froot.co.uk <mailto:
> > > g.rowe@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 <jim618@fastmail.co.uk <mailto:
> > > jim618@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 <
> > > gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
> > > >
> > > >
> > > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > >     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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> https://multibit.org    Money, 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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 18021 bytes --]

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

[Will]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Omaha - which is the automatic update framework that Google Chrome uses -
is open sourced:

https://code.google.com/p/omaha/

It might be a bit heavyweight for just one package though.

Will

On 9 July 2013 13:04, Mike Hearn <mike@plan99.net> wrote:

> For the auto update, is there an existing auto update framework that we
> can modify to support threshold signed updates? I'm sure such a thing must
> exist. The updates would download in the background and then the app can
> just ask the user to restart it once the update is locally available, as
> Chrome does.
>

[-- Attachment #2: Type: text/html, Size: 1086 bytes --]

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

[Jim]

Currently there are about 2,500 downloads a day for MultiBit.
There are download stats here:
https://multibit.org/awstats/awstats.pl?config=multibit.org

With a mirror from Mike and perhaps another instance at
multibit.org that would get us to 100K per day so probably
nothing to worry about.

I think the highest daily download stats I have seen were in the
April 2013 'boom' where Bitcoin-QT downloads hit 30K per day as
I recall.

The 30-40 MB including a JVM is based on the download sizes for
CharlesProxy.com which does this for their Windows downloads.
The sizes are here:
http://www.charlesproxy.com/download/

This is a Java codebase too.


Yes there must be an auto-update framework (but without 
ECDSA signing most likely). I haven't spent much time on this
yet.


On Tue, Jul 9, 2013, at 12:04 PM, Mike Hearn wrote:
> How many downloads/day do we see currently? I think you said it's on the
> order of a few thousand, so nowhere near 30k I'd guess. Anyway I can
> mirror
> it if we need to.
> 
> The JavaFX packager is supposed to delete parts of the JVM that aren't
> used. Is the 30-40mb figure based on using that tool or something else?
> Note that you don't need to use the JFX widget toolkit to use the bundler
> tool.
> 
> We could also invest in a copy of JET, which does native compilation down
> to self contained Windows binaries. It might create smaller bundles. But,
> it's a proprietary tool and I don't know how reproducible its outputs
> are.
> 
> For the auto update, is there an existing auto update framework that we
> can
> modify to support threshold signed updates? I'm sure such a thing must
> exist. The updates would download in the background and then the app can
> just ask the user to restart it once the update is locally available, as
> Chrome does.
> 
> 
> 
> On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail.co.uk> wrote:
> 
> > Yes I would like to bundle a JVM as it would simplify the user
> > experience.
> >
> > There are a few downsides though:
> > + all the build packaging will need redoing and retesting.
> > + 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.
> >
> > Currently there is no provision to update anything automatically.
> > I would like to start having Bitcoin signed files that MultiBit can
> > check
> > and update (initially the checkpoints file, I18N files - NOT code
> > at first because of the security implications). I think this needs to be
> > in place before bundling a JVM so that users don't have to
> > keep redownloading it.
> >
> > Having lists of all the artifacts signed and them having SHA256 hashes
> > then makes it practical/ safe to start mirroring the code. I can see
> > each mirror crosschecking the others that the SHA256s are correct
> > for instance. This would increase the maximum number of
> > downloads we could cope with.
> >
> >
> > On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> > > 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 <
> > > calebdelisle@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.rowe@froot.co.uk <mailto:
> > > > g.rowe@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 <jim618@fastmail.co.uk <mailto:
> > > > jim618@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 <
> > > > gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > >     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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> > --
> > https://multibit.org    Money, 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=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >


-- 
https://multibit.org    Money, reinvented

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 13678 bytes --]

By the way, the Java Web Start system has improved a lot in recent versions
as well. I just tried running http://jfxtras.org/ and this was the
experience:

   - It told me my Java was insecure and that I should download the latest
   version (hah). It had three buttons, one saying "Update", one saying "Block
   content in browser" and one saying "Later". So it seems Java learned how to
   disable its plugin by itself anyway. I think on non-Linux platforms it
   probably knows how to update itself as well these days.
   - As it happens I don't care right now because jfxtras is a source I
   trust, so I clicked later and it popped up a permission screen saying the
   author was unknown, could damage my computer, etc. Actually, Jim has a code
   signing cert so this would show his identity at that point.
   - Clicked run. The app downloaded in a few seconds and was running.
   - JavaWS keeps the app up to date for you at that point.

It's triggered by downloading and opening a .jnlp file, so - same security
boundaries as a regular app download, except you download metadata for the
runtime instead of the whole app at once.

It might be worth providing a JNLP option on the multibit webpage as well,
as although I wouldn't let the applet plugin in my browser, once I made an
explicit decision to go to multibit.org and trust James Burton with my
money, the JWS experience at that point is pretty good. Until we have our
own auto update engine it's better than nothing.



On Tue, Jul 9, 2013 at 1:04 PM, Mike Hearn <mike@plan99.net> wrote:

> How many downloads/day do we see currently? I think you said it's on the
> order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror
> it if we need to.
>
> The JavaFX packager is supposed to delete parts of the JVM that aren't
> used. Is the 30-40mb figure based on using that tool or something else?
> Note that you don't need to use the JFX widget toolkit to use the bundler
> tool.
>
> We could also invest in a copy of JET, which does native compilation down
> to self contained Windows binaries. It might create smaller bundles. But,
> it's a proprietary tool and I don't know how reproducible its outputs are.
>
> For the auto update, is there an existing auto update framework that we
> can modify to support threshold signed updates? I'm sure such a thing must
> exist. The updates would download in the background and then the app can
> just ask the user to restart it once the update is locally available, as
> Chrome does.
>
>
>
> On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618@fastmail.co.uk> wrote:
>
>> Yes I would like to bundle a JVM as it would simplify the user
>> experience.
>>
>> There are a few downsides though:
>> + all the build packaging will need redoing and retesting.
>> + 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.
>>
>> Currently there is no provision to update anything automatically.
>> I would like to start having Bitcoin signed files that MultiBit can
>> check
>> and update (initially the checkpoints file, I18N files - NOT code
>> at first because of the security implications). I think this needs to be
>> in place before bundling a JVM so that users don't have to
>> keep redownloading it.
>>
>> Having lists of all the artifacts signed and them having SHA256 hashes
>> then makes it practical/ safe to start mirroring the code. I can see
>> each mirror crosschecking the others that the SHA256s are correct
>> for instance. This would increase the maximum number of
>> downloads we could cope with.
>>
>>
>> On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
>> > 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 <
>> > calebdelisle@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.rowe@froot.co.uk <mailto:
>> > > g.rowe@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 <jim618@fastmail.co.uk <mailto:
>> > > jim618@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 <
>> > > gavinandresen@gmail.com <mailto:gavinandresen@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.org    Money, 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
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> ------------------------------------------------------------------------------
>> > > >     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
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> ------------------------------------------------------------------------------
>> > > > 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> --
>> https://multibit.org    Money, 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=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>

[-- Attachment #2: Type: text/html, Size: 20387 bytes --]

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

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

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

[Jeff Garzik]

On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@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/

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

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 <jgarzik@bitpay.com> wrote:

> On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2707 bytes --]

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

[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 <jgarzik@bitpay.com> wrote:
> 
> > On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube@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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.org    Money, reinvented

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

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

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

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 <nanotube@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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2212 bytes --]

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

[Nick Simpson]

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

What about something like Cloudflare? Transparent to most and it'd help with your bandwidth issues.


Mike Hearn <mike@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 <nanotube@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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 3572 bytes --]

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

[Johnathan Corgan]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

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
<johnathan@corganlabs.com>wrote:

> 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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2231 bytes --]

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

[Jeff Garzik]

On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson <nick@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/

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

[Nick Simpson]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Not any more than sourceforge or github.. None of these solutions are replacements, but rather only supplements to self hosted files.

Jeff Garzik <jgarzik@bitpay.com> wrote:
>On Tue, Jul 9, 2013 at 11:32 AM, Nick Simpson <nick@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/

[-- Attachment #2: Type: text/html, Size: 807 bytes --]

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

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

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

[Gregory Maxwell]

On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@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?

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

[Alex Kravets]

[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]

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 <gmaxwell@gmail.com>wrote:

> On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@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 ]]

[-- Attachment #2: Type: text/html, Size: 3228 bytes --]

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

[Caleb James DeLisle]

On 06/27/2013 01:56 PM, Gregory Maxwell wrote:
> On Thu, Jun 27, 2013 at 10:10 AM, Jim <jim618@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
> 

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

[Mike Hearn]

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

Yes. There were a number of lock cycles that didn't cause issues so
much when traffic was lower and as Bitcoin got more popular it became
a critical problem. I redid a lot of the concurrency to fix that, and
now all the core locks are cycle detecting so regressions should be
detected fairly fast. I'm still making changes to the concurrency
design but mostly to improve the API at this point, not fix bugs.

There is one deadlock I'm still aware of, thanks to Netty. However
it's very rare and was only reported by someone who kept a server
running for many days in a row. We want to junk Netty soon anyway.
It's a network library but it doesn't really add much value for our
use case and it turned out to have some serious design issues
internally.

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

> that it reuses addresses (esp for change), that it doesn't clearly
> distinguish confirmation level.

It does actually, but the iconography is not very clear. I'm not
convinced any users really care about the difference between two and
three blocks these days. Maybe exchanges and other security-critical
applications do, but I doubt desktop users do.

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"
vs "3 confirms", something that would just make a new user ask what
the heck a confirm is.

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

[John Dillon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@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

[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.dillon892@googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn <mike@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

[John Dillon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn <mike@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-----

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]

On Fri, Jun 28, 2013 at 10:09:16AM +0000, 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: x0000000000000003.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
00000000000000b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]