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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TgCRw-0004XQ-Hn for bitcoin-development@lists.sourceforge.net; Wed, 05 Dec 2012 10:43:32 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.47 as permitted sender) client-ip=209.85.214.47; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f47.google.com; Received: from mail-bk0-f47.google.com ([209.85.214.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TgCRv-0006Cd-GS for bitcoin-development@lists.sourceforge.net; Wed, 05 Dec 2012 10:43:32 +0000 Received: by mail-bk0-f47.google.com with SMTP id j4so2057409bkw.34 for ; Wed, 05 Dec 2012 02:43:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.147.139 with SMTP id l11mr5322786bkv.46.1354704205093; Wed, 05 Dec 2012 02:43:25 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.204.34.141 with HTTP; Wed, 5 Dec 2012 02:43:24 -0800 (PST) In-Reply-To: References: <50BEACAB.3070304@gmail.com> Date: Wed, 5 Dec 2012 11:43:24 +0100 X-Google-Sender-Auth: 6p7WIM6A0pYvNRptrdITRLU0Ugg Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1TgCRv-0006Cd-GS Cc: Bitcoin Dev 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 10:43:32 -0000 >> I was under the impression that "connectedness" was the real metric of >> concern I think the real thing we need full nodes for is "sockets" where by socket I mean "resources needed to serve another node". Last year we actually ran out of sockets and it took forever for new nodes to connect because so many existing nodes were full. We don't want to be in that situation again. So we need full nodes, nobody disputes that. The question is, if you have a node on your average desktop machine that gets switched off at night, has a stupid virus scanner that insists on checking every database write, has users who go from a bit of light word processing to watching HD video and expect no stutters or slowdowns - how valuable is such a node, really? Also has to be weighed against the risk of eventual user frustration when they discover Bitcoin is slowing their computer down and go around telling their friends how much it sucks. Ultraprune+LevelDB+other optimizations are great. They aren't game changers for two reasons: 1) Eventually network traffic should increase to use up the additional performance unlocked by optimizations 2) Users demand instant on not just at first start, but any time they open their wallet. I don't think it ever makes sense for a regular end user to have their wallet integrated with a full node because it means if you get an email saying "oh hey I sent you the money" and you start your wallet so you can see it/spend it, you still have to wait a while until it catches up from whenever it was last quit. I've done this a bunch of times and it really sucks to wait. The only time it makes sense to have a wallet integrated with a full node is if that node never shuts down, ie, it's a merchant node. If a casual user has to be using an SPV wallet all the time no matter what, then it's not a big leap to simply have both an SPV client and a full node running in parallel for users who want to support the network. And how do we recruit such users? Well I've got nothing against light wallets noticing that the system seems to have high uptime, external connectivity etc and putting a notice on the screen asking users to take part. For Windows users you could have a one-click install that sets up a background service (I think .NET OneClick makes this possible), so getting a full node is totally easy and transparent. Going back to the Tor analogy, whilst I agree with Gregorys arguments that they aren't quite the same, the Tor guys have wanted to automatically opt users in to being relays for a while. But the technical complexity of doing it well is really high. It's still on their wishlist even though Tor is quite old. A good first base to reach is simply having accurate recommendations. If users start complaining that they were asked to run a full node but when they did, performance suffered unacceptably, then we know we need better heuristics before automatically opting users in.