1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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.
|
