public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay.com>
To: Jim <jim618@fastmail.co.uk>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Date: Thu, 27 Jun 2013 13:30:21 -0400	[thread overview]
Message-ID: <CAJHLa0Ncac9Xt-AQBnpghqqpfR-j6Xtd9qVQoUe2dPp0kJvz1A@mail.gmail.com> (raw)
In-Reply-To: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com>

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/



  reply	other threads:[~2013-06-27 17:30 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 17:10 [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org Jim
2013-06-27 17:30 ` Jeff Garzik [this message]
2013-06-27 18:04   ` Luke-Jr
2013-06-27 18:41     ` Gregory Maxwell
2013-06-27 19:18       ` Jim
2013-06-27 19:40         ` Jim
2013-06-27 19:50           ` Jim
2013-06-27 21:12         ` Alex Kravets
2013-06-27 21:56           ` Jeff Garzik
2013-06-27 22:53             ` Alex Kravets
2013-06-27 22:03           ` Gary Rowe
2013-06-28 10:59       ` John Dillon
2013-06-28  9:10   ` Mike Hearn
2013-06-28 14:24     ` Gavin Andresen
     [not found]       ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com>
2013-06-28 20:37         ` Bill Hees
2013-06-28 20:42           ` Jim
2013-06-30 11:42       ` Mike Hearn
2013-06-30 15:19         ` Jim
2013-06-30 16:39           ` Gary Rowe
2013-07-09  0:22             ` Robert Backhaus
2013-07-09  1:20               ` Caleb James DeLisle
2013-07-09 10:36                 ` Mike Hearn
2013-07-09 10:56                   ` Jim
2013-07-09 11:04                     ` Mike Hearn
2013-07-09 11:13                       ` Will
2013-07-09 11:15                       ` Jim
2013-07-09 11:18                       ` Mike Hearn
2013-07-09 14:00                     ` Daniel F
2013-07-09 14:06                       ` Jeff Garzik
2013-07-09 14:28                         ` Mike Hearn
2013-07-09 14:46                           ` Jim
2013-07-09 14:57                           ` Daniel F
2013-07-09 15:27                             ` Mike Hearn
2013-07-09 15:32                               ` Nick Simpson
2013-07-09 15:51                                 ` Johnathan Corgan
2013-07-09 16:44                                   ` Mike Hearn
2013-07-09 15:59                                 ` Jeff Garzik
2013-07-09 16:03                                   ` Nick Simpson
2013-07-09 22:15                                   ` Andreas Petersson
2013-06-27 17:56 ` Gregory Maxwell
2013-06-27 18:05   ` Alex Kravets
2013-06-27 23:45   ` Caleb James DeLisle
2013-06-28  9:05   ` Mike Hearn
2013-06-28 10:09     ` John Dillon
2013-06-28 10:20       ` Mike Hearn
2013-06-28 10:32         ` John Dillon
2013-06-30 10:12       ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJHLa0Ncac9Xt-AQBnpghqqpfR-j6Xtd9qVQoUe2dPp0kJvz1A@mail.gmail.com \
    --to=jgarzik@bitpay.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jim618@fastmail.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox