Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsJUg-0007RM-B7 for bitcoin-development@lists.sourceforge.net; Thu, 27 Jun 2013 21:12:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.42 as permitted sender) client-ip=209.85.160.42; envelope-from=kravets@gmail.com; helo=mail-pb0-f42.google.com; Received: from mail-pb0-f42.google.com ([209.85.160.42]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsJUe-0002rM-EL for bitcoin-development@lists.sourceforge.net; Thu, 27 Jun 2013 21:12:42 +0000 Received: by mail-pb0-f42.google.com with SMTP id un1so1434362pbc.1 for ; Thu, 27 Jun 2013 14:12:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.164.33 with SMTP id yn1mr8083209pbb.71.1372367554472; Thu, 27 Jun 2013 14:12:34 -0700 (PDT) Received: by 10.66.250.163 with HTTP; Thu, 27 Jun 2013 14:12:34 -0700 (PDT) In-Reply-To: <1372360716.14869.140661249272837.1376DACB@webmail.messagingengine.com> 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 14:12:34 -0700 Message-ID: From: Alex Kravets To: Jim Content-Type: multipart/alternative; boundary=047d7b62434095f3c504e02938b4 X-Spam-Score: 0.0 (/) 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 (kravets[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: dashjr.org] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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 X-Headers-End: 1UsJUe-0002rM-EL Cc: bitcoin-development@lists.sourceforge.net 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 21:12:42 -0000 --047d7b62434095f3c504e02938b4 Content-Type: text/plain; charset=UTF-8 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 ]] --047d7b62434095f3c504e02938b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618@fastmail.co.u= k> 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 in earl= y 2012), I can tell you that this particular asylum is definitely run by it= s 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 precisely because they don't trouble regular lawyers and doctors wit= h all the nonsense but simply give them a=C2=A0
"buy&q= uot; and a "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<= /a>
[[ brutal honesty is = the best policy ]]
--047d7b62434095f3c504e02938b4--