From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Date: Wed, 5 Dec 2012 11:43:24 +0100 [thread overview]
Message-ID: <CANEZrP2W8BnDOBHJY08Pv9x1sOZ_BS7HHQk60Ysk_yFNH+RM5A@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRfUMYwOE51+eY5QE8nDNV==G1OBRzM1AuHjYmYwTFiow@mail.gmail.com>
>> 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.
next prev parent reply other threads:[~2012-12-05 10:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 17:46 Mike Hearn
2012-12-04 18:03 ` Alan Reiner
2012-12-04 18:08 ` Will
2012-12-04 18:17 ` Gregory Maxwell
2012-12-04 20:58 ` Mike Hearn
2012-12-04 21:41 ` Gregory Maxwell
2012-12-04 22:44 ` Alan Reiner
2012-12-05 0:27 ` Gregory Maxwell
2012-12-05 2:08 ` Alan Reiner
2012-12-05 2:54 ` Gregory Maxwell
2012-12-05 5:38 ` Jim Nguyen
2012-12-05 7:50 ` Wladimir
2012-12-05 9:43 ` Gary Rowe
2012-12-05 10:19 ` Robert Backhaus
2012-12-05 10:43 ` Mike Hearn [this message]
2012-12-04 18:57 ` Mark Friedenbach
2012-12-04 19:36 ` Gregory Maxwell
[not found] <mailman.70419.1354648162.2176.bitcoin-development@lists.sourceforge.net>
2012-12-04 19:56 ` Jim
2012-12-04 22:23 ` slush
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP2W8BnDOBHJY08Pv9x1sOZ_BS7HHQk60Ysk_yFNH+RM5A@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox