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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 009778A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:05:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 889D3212
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:05:30 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so70686593wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 11:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=+zoaCT4gqG9hQIj5S4TYV8kFLdVEeRVsKOczGpB+Ay0=;
b=nHdIRol+QdnCPlgw6PI0j9CwQ44DBHaLzXmXJYw10mx0Uzag6SIt8mJXmAuyQH/ffE
6mxtEyP8l8ASy5QgJv6rFVDz60WfQFaf4h7BqQJtBWcLRmM4aplo0n38TfZ7CB4j1DxH
zlr4GQRUyiyHvqPBhMMFSWgphyv/dfD3t3fTGM7iIX77xIKg4hhsAeq1MInRyIB/dbRC
R3EVO0Jr/RiUIu4ZmTC7fC2Bc3hH7meQw/FoODpArSwnCmGGG+M9+03j/mdLKfOkNmN5
KgsdkFcTSJXLkClTjUD2Xml9Wi3svjYicJYZ7bfmByqMcSaq7VDJijDRZxJcXB+az/sr
TtZA==
MIME-Version: 1.0
X-Received: by 10.180.218.195 with SMTP id pi3mr9263873wic.71.1438970729305;
Fri, 07 Aug 2015 11:05:29 -0700 (PDT)
Received: by 10.27.171.138 with HTTP; Fri, 7 Aug 2015 11:05:29 -0700 (PDT)
In-Reply-To: <CABsx9T3kwATCovg2FeamNPdJbhM_ypJEd_6fcwfknYsKCBQkbQ@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CALgxB7vqA=o1L0aftMtzNYC_OYJcVw6vuqUeB3a2F6d+VuoJkA@mail.gmail.com>
<CAPg+sBj1qCRvtZ2F1v_1JUTqwws6JOmi+8BYKVoCWPRBSs-Y=g@mail.gmail.com>
<1542978.eROxFinZd4@coldstorage>
<CAPg+sBiCH12i6-WEx++zTbovn=2FZqKAKxfnGkruU_Ah-y-_4g@mail.gmail.com>
<CABsx9T3kwATCovg2FeamNPdJbhM_ypJEd_6fcwfknYsKCBQkbQ@mail.gmail.com>
Date: Fri, 7 Aug 2015 14:05:29 -0400
Message-ID: <CADL_X_fUTaMZDDbMbgHvQW5DqA-W7iFRLCZ2Fj0TX+aSX5ZyQw@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134ce04299b31051cbc7be7
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fwd: Block size following technological growth
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 18:05:32 -0000
--001a1134ce04299b31051cbc7be7
Content-Type: text/plain; charset=UTF-8
Anecdotally I've seen two primary reasons posed for not running a node:
1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
configuration option in bitcoind and a slider / selector in the QT client
to throttle the total bandwidth usage. This issue has been open for years:
https://github.com/bitcoin/bitcoin/issues/273 - if you want to make it
easier for enthusiasts to run nodes, I'd start there.
2) For businesses, it's not so much an issue with the resources of
installing / running / maintaining a node, it's an issue with the lack of
indexing options offered by bitcoind. Thus the business will also need to
run their own indexing solution - an out-of-the-box solution such as
Insight or Toshi might work, but for more custom indexing you have to roll
your own software - this is where it actually becomes expensive.
Depending upon the query volume / latency needs of the business, it may not
make sense to bother administering bitcoind instances, the indexing
software, and its databases - using a third party API will probably be more
efficient.
- Jameson
On Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the incentives for running a node don't weight up against the
>> cost/difficulty using a full node yourself for a majority of people in the
>> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
>> improvement over other systems is the lack of need for trust, I believe
>> that with increased adoption should also come an increased (in absolute
>> terms) incentive for people to use a full node. I'm seeing the opposite
>> trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
> to trust nothing but the genesis block hash (decide to run a full node)
> there is a problem?
>
> If so, then we do have a fundamental difference of opinion, but I've
> misunderstood how you think about trust/centralization/convenience
> tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeoffs,
> and I believe that is OK-- people should be free to make those tradeoffs.
>
> And given that the majority of people in the ecosystem were deciding that
> using a centralized service or an SPV-level-security wallet was better even
> two or three years ago when blocks were tiny (I'd have to go back and dig
> up number-of-full-nodes and number-of-active-wallets at the big web-wallet
> providers, but I bet there were an order of magnitude more people using
> centralized services than running full nodes even back then), I firmly
> believe that block size has very little to do with the decision to run a
> full node or not.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1134ce04299b31051cbc7be7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Anecdotally I've seen two primary reasons posed for no=
t running a node:<div><br></div><div>1) For enthusiasts who want to altruis=
tically run a node at home, it's usually a bandwidth / quality of servi=
ce problem. There are tools to help work around this, but most users aren&#=
39;t sysadmins and would prefer a simple configuration option in bitcoind a=
nd a slider / selector in the QT client to throttle the total bandwidth usa=
ge. This issue has been open for years: <a href=3D"https://github.com/bitco=
in/bitcoin/issues/273">https://github.com/bitcoin/bitcoin/issues/273</a> - =
if you want to make it easier for enthusiasts to run nodes, I'd start t=
here.</div><div><br></div><div>2) For businesses, it's not so much an i=
ssue with the resources of installing / running / maintaining a node, it=
9;s an issue with the lack of indexing options offered by bitcoind. Thus th=
e business will also need to run their own indexing solution - an out-of-th=
e-box solution such as Insight or Toshi might work, but for more custom ind=
exing you have to roll your own software - this is where it actually become=
s expensive.</div><div><br></div><div>Depending upon the query volume / lat=
ency needs of the business, it may not make sense to bother administering b=
itcoind instances, the indexing software, and its databases - using a third=
party API will probably be more efficient.</div><div><br></div><div>- Jame=
son</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <span dir=3D"l=
tr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><spa=
n class=3D""><br><div class=3D"gmail_quote">On Fri, Aug 7, 2015 at 12:30 PM=
, Pieter Wuille via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If=
the incentives for running a node don't weight up against the cost/dif=
ficulty using a full node yourself for a majority of people in the ecosyste=
m, I would argue that there is a problem. As Bitcoin's fundamental impr=
ovement over other systems is the lack of need for trust, I believe that wi=
th increased adoption should also come an increased (in absolute terms) inc=
entive for people to use a full node. I'm seeing the opposite trend, an=
d that is worrying IMHO.</blockquote></div><br></span>Are you saying that u=
nless the majority of people in the ecosystem decide to trust nothing but t=
he genesis block hash (decide to run a full node) there is a problem?<br><b=
r>If so, then we do have a fundamental difference of opinion, but I've =
misunderstood how you think about trust/centralization/convenience tradeoff=
s in the past.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">I believe people in the Bitcoin ecosystem will choose different tr=
adeoffs, and I believe that is OK-- people should be free to make those tra=
deoffs.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">And given that the majority of people in the ecosystem were deciding that=
using a centralized service or an SPV-level-security wallet was better eve=
n two or three years ago when blocks were tiny (I'd have to go back and=
dig up number-of-full-nodes and number-of-active-wallets at the big web-wa=
llet providers, but I bet there were an order of magnitude more people usin=
g centralized services than running full nodes even back then), I firmly be=
lieve that block size has very little to do with the decision to run a full=
node or not.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div><br></div>-- <b=
r><div>--<br>Gavin Andresen<br></div><div><br></div>
</div></font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a1134ce04299b31051cbc7be7--
|
