Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <8AE1517F-88FB-479D-AE89-993A5545D210@jonasschnelli.ch>
Date: Wed, 29 Aug 2018 07:40:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org>
References: <CA+9w0-77oP3rmW37R6ty4fF_LhaOtQaL52yQUKynXEmZhQ9MeA@mail.gmail.com>
	<8AE1517F-88FB-479D-AE89-993A5545D210@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Blockchain Group <shekharhiran@gmail.com>
Subject: Re: [bitcoin-dev] Building a Bitcoin API and query system.
Precedence: list

The API implementation is not what is centralizing, nor is full indexation n=
on-scalable. The centralization is in not running the API from a node under y=
our own control. This is of course implied by the comment, =E2=80=9Cwithout t=
he need for syncing=E2=80=9D. In other words it is the deployment cost of th=
e node that is centralizing.

Yet if people relied only on bitcoind and never centralized services there w=
ould be *no* block explorers (and no secure light wallets), because it does n=
ot provide remote query and does not fully index.

Block explorers and light wallets are pretty useful, so presumably some API m=
ust provide these features (ideally with reduced deployment cost). That will=
 either be centralized or decentralized services. As such it seems wise to e=
ncourage the latter, as opposed to questioning whether there is any valid bl=
ock explorer use case.

e


> On Aug 28, 2018, at 11:36, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>=20
> Hi
>=20
> To give a critical viewpoint on a such API:
>=20
> Such APIs usually result in central validation, meaning that users trust A=
PI services rather the validating their own data. It break some of the funda=
mental properties of Bitcoin (avoid trusted third parties).
> Systems or applications depending on a full indexed blockchain (a thus suc=
h API) do usually scale pretty bad.
>=20
> I=E2=80=99d like to hear some concrete use-cases for a such block explorer=
(ish) API.
>=20
> Thanks
> =E2=80=94
> Jonas
>=20
>> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org>:
>>=20
>> Hello everyone,
>>=20
>> I am C++ & Node.js developer. I want to propose making a new Bitcoin API t=
hat supports fast quering of Bitcoin blocks and transactions without the nee=
d for syncing with all previous nodes.
>>=20
>> In a typical case where I want to build a full fleged Bitcoin explorer cu=
m wallet system on my end with external APIs, I need to sync my node and the=
n query for the information I need to show separately. I am proposing a unif=
ied method of finding/quering the blockchain data with a standardized templa=
te containing minimal information about the actual mined block or transactio=
n yet satify the need of what I want to query.
>>=20
>> I am working on making a template and a support mechanism on Node.js. I w=
ant to propose it as an improvement (BIP). It will be a great help to future=
 web developers who want to make something similar.
>>=20
>> Thanks
>> Sumit Lahiri.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev