MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fwd: Block size following technological growth
Precedence: list

--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&#39;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&#39;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&#39;d start t=
here.</div><div><br></div><div>2) For businesses, it&#39;s not so much an i=
ssue with the resources of installing / running / maintaining a node, it&#3=
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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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">&lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt;</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&#39;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&#39;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&#39;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&#39;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&#39;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--