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
125
126
127
128
129
130
131
132
133
134
135
136
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1Tg4RJ-0008I0-R0
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Dec 2012 02:10:21 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.54 as permitted sender)
client-ip=209.85.216.54; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f54.google.com;
Received: from mail-qa0-f54.google.com ([209.85.216.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tg4RI-0007Ii-TV
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Dec 2012 02:10:21 +0000
Received: by mail-qa0-f54.google.com with SMTP id j15so1523465qaq.13
for <bitcoin-development@lists.sourceforge.net>;
Tue, 04 Dec 2012 18:10:15 -0800 (PST)
Received: by 10.224.107.3 with SMTP id z3mr26028187qao.9.1354673415520;
Tue, 04 Dec 2012 18:10:15 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id cs3sm2109061qab.10.2012.12.04.18.10.14
(version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 18:10:14 -0800 (PST)
Message-ID: <50BEACAB.3070304@gmail.com>
Date: Tue, 04 Dec 2012 21:08:43 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@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>
In-Reply-To: <CAAS2fgQewysOG7eOHQxmLup4oLJK=jY=q-_4qTL6yKQ855g3ew@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.6 (-)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Tg4RI-0007Ii-TV
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 02:10:22 -0000
Our divergence is on two points (personal opinions):
(1) I don't think there is any real risk to the centralization of the
network by promoting a SPV (purely-consuming) node to brand-new users.
In my opinion (but I'm not as familiar with the networking as you), as
long as all full nodes are full-validation, the bottleneck will be
computation and bandwidth, long before a constant 10k nodes would be
insufficient to support propagating data through the network. In fact,
I was under the impression that "connectedness" was the real metric of
concern (and resilience of that connectedness to large percentage of
users disappearing suddenly). If that's true, above a certain number of
nodes, the connectedness isn't really going to get any better (I know
it's not really that simple, but I feel like it is up to 10x the current
network size).
(2) I think the current experience *is* really poor. You seem to
suggest that the question for these new users is whether they will use
full-node-or-lite-node, but I believe it will be a decision between
lite-node-or-nothing-at-all (losing interest altogether). Waiting a day
for the full node to synchronize, and then run into issues like
blkindex.dat corruption when their system crashes for some unrelated
reason and they have to resync for another day... they'll be gone in a
heartbeat.
Users need to experience, as quickly and easily as possible, that they
can move money across the world, without signing up for anything or
paying any fees. After they understand the value of the system and want
to use it, they are much more likely to become educated and willing to
support the network with full node.
-Alan
On 12/04/2012 07:27 PM, Gregory Maxwell wrote:
> On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>> Greg's point looks like it's veering towards "we don't want to grow
>> the network unless we're going to get more full nodes out of it."
> No…
>
> There is no fundamental completion between taking what actions we can
> to maximize the decentralization of the network and making the
> software maximally friendly and painless to get started with and use.
> It's possible— not even deep rocket science— to create software that
> accommodates both.
>
> And because of this, I don't think it's acceptable to promote
> solutions which may endanger the decentralization that makes the
> system worthwhile in the first place. If the current experience is so
> poor that you'd even consider talking about promoting directions which
> reduce its robustness then thats evidence that it would be worth
> finding more resources to make the experience better without doing
> anything the that reduces the model, even if you've got an argument
> that maybe we can get away with it. If there isn't interest in
> putting in more resources to make these improvements then maybe the
> issue isn't as bad as we think it is?
>
>> I think it is very much in everyone's interest here to encourage new users to start "using" Bitcoin, even if they don't "support" it.
> Absolutely— and yet that has nothing to do with promoting software to
> users which only consumes without directly contributing and which
> doesn't even have the capability to do so even if the user wants to
> (or much less, is indifferent).
|
