MIME-Version: 1.0
References: <CA+9w0-77oP3rmW37R6ty4fF_LhaOtQaL52yQUKynXEmZhQ9MeA@mail.gmail.com>
	<8AE1517F-88FB-479D-AE89-993A5545D210@jonasschnelli.ch>
	<758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org>
	<4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>
In-Reply-To: <4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>
From: Blockchain Group <shekharhiran@gmail.com>
Date: Wed, 29 Aug 2018 23:59:18 +0530
Message-ID: <CA+9w0-4-BL5dJCTXD80hVfgt-kZY8AtYzLg_2yCn1m7KeeVs=g@mail.gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/alternative; boundary="000000000000a1bed10574972325"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Building a Bitcoin API and query system.
Precedence: list

--000000000000a1bed10574972325
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Awesome, thanks for the information. I will work on it and keep it in mind.

On Wed, Aug 29, 2018, 11:57 PM Jonas Schnelli <dev@jonasschnelli.ch> wrote:

>
> > The API implementation is not what is centralizing, nor is full
> indexation non-scalable. The centralization is in not running the API fro=
m
> a node under your own control. This is of course implied by the comment,
> =E2=80=9Cwithout the need for syncing=E2=80=9D. In other words it is the =
deployment cost of
> the node that is centralizing.
>
> IMO an API that serves non verifiable data is supporting centralised
> validation. The =E2=80=9EAPI" which supports one of the most important pr=
operties
> in Bitcoin =E2=80=93 the ability to self-validate =E2=80=93 is the data a=
vailable via the
> p2p network.
>
> >
> > Yet if people relied only on bitcoind and never centralized services
> there would be *no* block explorers (and no secure light wallets), becaus=
e
> it does not provide remote query and does not fully index.
> >
> > Block explorers and light wallets are pretty useful, so presumably some
> API must provide these features (ideally with reduced deployment cost).
> That will either be centralized or decentralized services. As such it see=
ms
> wise to encourage the latter, as opposed to questioning whether there is
> any valid block explorer use case.
>
> Bitcoin-Core has all required features to partially =E2=80=9Eindex=E2=80=
=9C data (called
> the wallet) and provides them via the RPC API. If you don=E2=80=99t need =
to serve
> thousands of wallets (which smells after centralised validation), selecti=
ve
> indexing (wallets) are the right choice. Also, if you have a proper light
> client architecture, you can use Bitcoin Core in pruned mode (<10GB of
> data) to serve an endless amount of wallets (client/server mode, I guess
> that is what you are referring to with "light clients").
>
> I fail to see the use-cases where a fully index blockchain makes sense
> (the only one I can come up with is instant backup recovery where the
> transaction history needs to be preserved rather then recovering the UTXO=
s
> only).
>
> Also, the p2p protocol has built in light client support with BIP37 (bloo=
m
> filters) and soon BIP158 will be available on the network which does allo=
w
> privacy-preserving "light clients" in a way where no trusted layer is
> required (client <-> p2p network rather then client <-> API provider <->
> p2p network).
>
> I don=E2=80=99t want to advocate against a full-index blockexplorer-like =
API. I
> just think its important to define the use case and be aware of the
> consequences and downsides.
>
> /jonas
>

--000000000000a1bed10574972325
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Awesome, thanks for the information. I will work on it an=
d keep it in mind.=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Wed, Aug 29, 2018, 11:57 PM Jonas Schnelli &lt;<a href=3D"mailto:dev@=
jonasschnelli.ch">dev@jonasschnelli.ch</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><br>
&gt; The API implementation is not what is centralizing, nor is full indexa=
tion non-scalable. The centralization is in not running the API from a node=
 under your own control. This is of course implied by the comment, =E2=80=
=9Cwithout the need for syncing=E2=80=9D. In other words it is the deployme=
nt cost of the node that is centralizing.<br>
<br>
IMO an API that serves non verifiable data is supporting centralised valida=
tion. The =E2=80=9EAPI&quot; which supports one of the most important prope=
rties in Bitcoin =E2=80=93 the ability to self-validate =E2=80=93 is the da=
ta available via the p2p network.<br>
<br>
&gt; <br>
&gt; Yet if people relied only on bitcoind and never centralized services t=
here would be *no* block explorers (and no secure light wallets), because i=
t does not provide remote query and does not fully index.<br>
&gt; <br>
&gt; Block explorers and light wallets are pretty useful, so presumably som=
e API must provide these features (ideally with reduced deployment cost). T=
hat will either be centralized or decentralized services. As such it seems =
wise to encourage the latter, as opposed to questioning whether there is an=
y valid block explorer use case.<br>
<br>
Bitcoin-Core has all required features to partially =E2=80=9Eindex=E2=80=9C=
 data (called the wallet) and provides them via the RPC API. If you don=E2=
=80=99t need to serve thousands of wallets (which smells after centralised =
validation), selective indexing (wallets) are the right choice. Also, if yo=
u have a proper light client architecture, you can use Bitcoin Core in prun=
ed mode (&lt;10GB of data) to serve an endless amount of wallets (client/se=
rver mode, I guess that is what you are referring to with &quot;light clien=
ts&quot;).<br>
<br>
I fail to see the use-cases where a fully index blockchain makes sense (the=
 only one I can come up with is instant backup recovery where the transacti=
on history needs to be preserved rather then recovering the UTXOs only).<br=
>
<br>
Also, the p2p protocol has built in light client support with BIP37 (bloom =
filters) and soon BIP158 will be available on the network which does allow =
privacy-preserving &quot;light clients&quot; in a way where no trusted laye=
r is required (client &lt;-&gt; p2p network rather then client &lt;-&gt; AP=
I provider &lt;-&gt; p2p network).<br>
<br>
I don=E2=80=99t want to advocate against a full-index blockexplorer-like AP=
I. I just think its important to define the use case and be aware of the co=
nsequences and downsides.<br>
<br>
/jonas<br>
</blockquote></div>

--000000000000a1bed10574972325--