From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TgD7V-0005f5-H1 for bitcoin-development@lists.sourceforge.net; Wed, 05 Dec 2012 11:26:29 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of robbak.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43; envelope-from=robbak@robbak.com; helo=mail-wg0-f43.google.com; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TgD7R-0006Rf-A7 for bitcoin-development@lists.sourceforge.net; Wed, 05 Dec 2012 11:26:29 +0000 Received: by mail-wg0-f43.google.com with SMTP id e12so2413503wge.10 for ; Wed, 05 Dec 2012 03:26:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Uxb3dKXRlJJqKe5LQt3/2qs1ViG7L2IOUZmttdmEBGU=; b=IUYsU7Yoy6JdNd18euOGR+htZwJUW/q8IIDW7vEtzV2pQ3D7VfMJPDmxcXdmr/1VAL WvnZQUyBtL82YDszAl0Uh1cRR9xlpq3Li3VKyRx2UQJtr1eQmQzMTH0bqUA/knRn8SLB Zn6hhmqmNJ0H6OzSOnAdG6vDBpdsSdcgnQ24/vSu9G1WLlvNIuGLAWmH/RlC7OFXY4K/ mZBAXjApUGTmvAb8SUn6AgWJpce4cLi9WEu8DO0ZQS0UHhobRzZpRT+a88UaxHwzn5mT TBVke9TTUwt4PrTp4s2yHAxPb8sYCKCACjNTcdTm09Plm9w0xwBAzYhXk8Ij4NwiP0Ga WKHg== MIME-Version: 1.0 Received: by 10.180.108.38 with SMTP id hh6mr2280619wib.0.1354702756620; Wed, 05 Dec 2012 02:19:16 -0800 (PST) Received: by 10.194.71.109 with HTTP; Wed, 5 Dec 2012 02:19:16 -0800 (PST) In-Reply-To: References: <50BEACAB.3070304@gmail.com> Date: Wed, 5 Dec 2012 20:19:16 +1000 Message-ID: From: Robert Backhaus To: Bitcoin Dev Content-Type: multipart/alternative; boundary=e89a8f3ba5c195a94104d0185030 X-Gm-Message-State: ALoCoQktaez6vOgTXpOgJ1x79HyaTYU7YViv3So9Jr/wSdfvk0m0wYuMq4i4S4gdrocP7DnVXejP X-Spam-Score: -0.5 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1TgD7R-0006Rf-A7 Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients 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: Wed, 05 Dec 2012 11:26:29 -0000 --e89a8f3ba5c195a94104d0185030 Content-Type: text/plain; charset=ISO-8859-1 On 5 December 2012 19:43, Gary Rowe wrote: > I would like to chime on on the user experience of the SPV client (in > particular MultiBit). > > Without exception, everyone that I have introduced Bitcoin (which is a lot > of people) have expected an "instant-on" experience. It has to clobber > PayPal and credit cards or people won't give it a second look, let alone a > second chance. SPV clients deliver on that expectation. > > Once the user has the great initial "wow!" moment then their interest in > Bitcoin is reinforced and they tend to explore further, particularly into > the economic theory behind it. Many decide to install the full node out of > a sense of community contribution to the security of the network. > > Having a hybrid mode of SPV first then full node second should be > something that a user has control over - it is their computing resources we > are using after all and Bitcoin should not be perceived as a drain. Hybrid SPV sounds like a good idea to me. Allows it to work out-of-the-box, then slowly gets up-to-speed with the full network - working low priority, or even not at all, if it detects a slow system or network link. Another idea is always distributing the client with a checkpoint that is only days old, then starting by pulling in more recent blocks, so it can transact. Following that, it will pull in progressively older blocks as time permits. --e89a8f3ba5c195a94104d0185030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 5 December 2012 19= :43, Gary Rowe <g.rowe@froot.co.uk> wrote:
I would like to chime on on the user experience of the SPV client (in parti= cular MultiBit).

Without exception, everyone that I have introduced= Bitcoin (which is a lot of people) have expected an "instant-on"= experience. It has to clobber PayPal and credit cards or people won't = give it a second look, let alone a second chance. SPV clients deliver on th= at expectation.

Once the user has the great initial "wow!" moment then their = interest in Bitcoin is reinforced and they tend to explore further, particu= larly into the economic theory behind it. Many decide to install the full n= ode out of a sense of community contribution to the security of the network= .

Having a hybrid mode of SPV first then full node second should be somet= hing that a user has control over - it is their computing resources we are = using after all and Bitcoin should not be perceived as a drain.

Hybrid SPV sounds like a good idea to me. Allows it to work out-of= -the-box, then slowly gets up-to-speed with the full network - working low = priority, or even not at all, if it detects a slow system or network link. =
Another idea is always distributing the client with a checkpoint that is on= ly days old, then starting by pulling in more recent blocks, so it can tran= sact. Following that, it will pull in progressively older blocks as time pe= rmits.
--e89a8f3ba5c195a94104d0185030--