diff options
author | Mike Hearn <mike@plan99.net> | 2012-12-05 11:43:24 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-05 10:43:32 +0000 |
commit | e7cd41ab3a7f204c8d7e9fd6d2e31c5da53e964e (patch) | |
tree | f572dfe76d609fea792642eec3e3c9fd4e8c794b | |
parent | a1aa5c92b639ee4f4eddc3daf8065911da8dea26 (diff) | |
download | pi-bitcoindev-e7cd41ab3a7f204c8d7e9fd6d2e31c5da53e964e.tar.gz pi-bitcoindev-e7cd41ab3a7f204c8d7e9fd6d2e31c5da53e964e.zip |
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
-rw-r--r-- | 43/9b0d98b9ec6dcebda78ae2ff543eaa6284c2c8 | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/43/9b0d98b9ec6dcebda78ae2ff543eaa6284c2c8 b/43/9b0d98b9ec6dcebda78ae2ff543eaa6284c2c8 new file mode 100644 index 000000000..4f9e5bc48 --- /dev/null +++ b/43/9b0d98b9ec6dcebda78ae2ff543eaa6284c2c8 @@ -0,0 +1,124 @@ +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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com> +References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com> + <CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com> + <CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com> + <CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@mail.gmail.com> + <CALf2ePw82wt08_G2RtUYEBxorjY1ryZ4r+W7atSzDLYMU+rGGQ@mail.gmail.com> + <CAAS2fgQewysOG7eOHQxmLup4oLJK=jY=q-_4qTL6yKQ855g3ew@mail.gmail.com> + <50BEACAB.3070304@gmail.com> + <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com> +Date: Wed, 5 Dec 2012 11:43:24 +0100 +X-Google-Sender-Auth: 6p7WIM6A0pYvNRptrdITRLU0Ugg +Message-ID: <CANEZrP2W8BnDOBHJY08Pv9x1sOZ_BS7HHQk60Ysk_yFNH+RM5A@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Gregory Maxwell <gmaxwell@gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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. + + |