Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>
Date: Wed, 29 Aug 2018 11:45:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <43C5B077-AFFB-4FCB-8D43-C56FBF835526@voskuil.org>
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>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Blockchain Group <shekharhiran@gmail.com>
Subject: Re: [bitcoin-dev] Building a Bitcoin API and query system.
Precedence: list

You have created a straw man.

And light clients working against the P2P network (anonymous nodes) implies t=
hey are not fully validating, so you are contradicting yourself.

e

> On Aug 29, 2018, at 11:27, Jonas Schnelli <dev@jonasschnelli.ch> wrote:
>=20
>=20
>> The API implementation is not what is centralizing, nor is full indexatio=
n non-scalable. The centralization is in not running the API from a node und=
er your own control. This is of course implied by the comment, =E2=80=9Cwith=
out the need for syncing=E2=80=9D. In other words it is the deployment cost o=
f the node that is centralizing.
>=20
> IMO an API that serves non verifiable data is supporting centralised valid=
ation. The =E2=80=9EAPI" which supports one of the most important properties=
 in Bitcoin =E2=80=93 the ability to self-validate =E2=80=93 is the data ava=
ilable via the p2p network.
>=20
>>=20
>> Yet if people relied only on bitcoind and never centralized services ther=
e would be *no* block explorers (and no secure light wallets), because it do=
es not provide remote query and does not fully index.
>>=20
>> Block explorers and light wallets are pretty useful, so presumably some A=
PI must provide these features (ideally with reduced deployment cost). That w=
ill either be centralized or decentralized services. As such it seems wise t=
o encourage the latter, as opposed to questioning whether there is any valid=
 block explorer use case.
>=20
> 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 vali=
dation), selective indexing (wallets) are the right choice. Also, if you hav=
e a proper light client architecture, you can use Bitcoin Core in pruned mod=
e (<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").
>=20
> I fail to see the use-cases where a fully index blockchain makes sense (th=
e 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).
>=20
> 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 p=
rivacy-preserving "light clients" in a way where no trusted layer is require=
d (client <-> p2p network rather then client <-> API provider <-> p2p networ=
k).
>=20
> I don=E2=80=99t want to advocate against a full-index blockexplorer-like A=
PI. I just think its important to define the use case and be aware of the co=
nsequences and downsides.
>=20
> /jonas