From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsKHl-0001EY-LW for bitcoin-development@lists.sourceforge.net; Thu, 27 Jun 2013 22:03:25 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.179 as permitted sender) client-ip=209.85.216.179; envelope-from=g.rowe.froot@gmail.com; helo=mail-qc0-f179.google.com; Received: from mail-qc0-f179.google.com ([209.85.216.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsKHk-0001BM-5p for bitcoin-development@lists.sourceforge.net; Thu, 27 Jun 2013 22:03:25 +0000 Received: by mail-qc0-f179.google.com with SMTP id e11so902646qcx.38 for ; Thu, 27 Jun 2013 15:03:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.53.200 with SMTP id n8mr1723392qag.88.1372370598502; Thu, 27 Jun 2013 15:03:18 -0700 (PDT) Sender: g.rowe.froot@gmail.com Received: by 10.49.53.97 with HTTP; Thu, 27 Jun 2013 15:03:18 -0700 (PDT) In-Reply-To: References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com> <201306271804.51009.luke@dashjr.org> <1372360716.14869.140661249272837.1376DACB@webmail.messagingengine.com> Date: Thu, 27 Jun 2013 23:03:18 +0100 X-Google-Sender-Auth: h6_gNUR6FZzO2LDQ_R3HgFhGPrE Message-ID: From: Gary Rowe To: Bitcoin Development List Content-Type: multipart/alternative; boundary=001a1132eac60626a204e029eec4 X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g.rowe.froot[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: dashjr.org] X-Headers-End: 1UsKHk-0001BM-5p Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 22:03:25 -0000 --001a1132eac60626a204e029eec4 Content-Type: text/plain; charset=UTF-8 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 wrote: > Hi Jim, > > On Thu, Jun 27, 2013 at 12:18 PM, Jim 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 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 def redPill = ' > Scala > [[ brutal honesty 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 > > --001a1132eac60626a204e029eec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Many people that I have introduced Bitcoin to have balked = at the massive blockchain download. When I showed them MultiBit (and Bitcoi= n 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 ave= rage low-tech user with a great client experience right from the word go th= en 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 strength= en the network overall.


<= br>
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.co= m. They are both good wallets
but I'd like to keep Bitcoin as P2P as possible.
<= br>
Guys, being a late comer/outsider (I got into bitcoin i= n early 2012), I can tell you that this particular asylum is definitely run= by its inmates.=C2=A0

What all the nerdy devs (and I am one so I know) seem u= nable 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 unnecessa= ry (there's plenty of nodes and NAT'ed home nodes which don't m= ine are mostly useless anyways)

P.S. coinbase.com is = just another trust-me setup takes your coins in exchange for IOUs, whereas= =C2=A0blockchain.info<= /a>=C2=A0does let you to retain control of your private keys.

P.P.S. The reason why coinbase has gotten so big is pre= cisely because they don't trouble regular lawyers and doctors with all = the nonsense but simply give them a=C2=A0
"buy" and a &= quot;sell" button.

=C2=A0

=C2=A0
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 n= odes on P2P
> >> network
> > Even a reduction of *nodes at all*, as I've never seen a list= ening 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/bitco= in-development


--
https://multibit.org= =C2=A0 =C2=A0Money, 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-de= velopment



--
Alex Kravets=C2=A0 =C2=A0 =C2=A0=C2=A0 def redPill =3D 'Scala
[[ brutal honesty 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a1132eac60626a204e029eec4--