From: Eric Voskuil <eric@voskuil.org>
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.
Date: Wed, 29 Aug 2018 07:40:16 -0700 [thread overview]
Message-ID: <758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org> (raw)
In-Reply-To: <8AE1517F-88FB-479D-AE89-993A5545D210@jonasschnelli.ch>
The API implementation is not what is centralizing, nor is full indexation 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, “without the need for syncing”. In other words it is the deployment cost of the node that is centralizing.
Yet if people relied only on bitcoind and never centralized services there would be *no* block explorers (and no secure light wallets), because 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 seems wise to encourage the latter, as opposed to questioning whether there is any valid block explorer use case.
e
> On Aug 28, 2018, at 11:36, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi
>
> To give a critical viewpoint on a such API:
>
> Such APIs usually result in central validation, meaning that users trust API services rather the validating their own data. It break some of the fundamental properties of Bitcoin (avoid trusted third parties).
> Systems or applications depending on a full indexed blockchain (a thus such API) do usually scale pretty bad.
>
> I’d like to hear some concrete use-cases for a such block explorer(ish) API.
>
> Thanks
> —
> Jonas
>
>> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
>>
>> Hello everyone,
>>
>> I am C++ & Node.js developer. I want to propose making a new Bitcoin API that supports fast quering of Bitcoin blocks and transactions without the need for syncing with all previous nodes.
>>
>> In a typical case where I want to build a full fleged Bitcoin explorer cum wallet system on my end with external APIs, I need to sync my node and then query for the information I need to show separately. I am proposing a unified method of finding/quering the blockchain data with a standardized template containing minimal information about the actual mined block or transaction yet satify the need of what I want to query.
>>
>> I am working on making a template and a support mechanism on Node.js. I want to propose it as an improvement (BIP). It will be a great help to future web developers who want to make something similar.
>>
>> Thanks
>> Sumit Lahiri.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2018-08-29 14:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-26 19:58 [bitcoin-dev] Building a Bitcoin API and query system Blockchain Group
2018-08-28 15:15 ` Joseph Gleason ⑈
2018-08-28 15:47 ` Matias Alejo Garcia
2018-08-28 17:34 ` Blockchain Group
2018-08-28 17:51 ` Guido Dassori
2018-08-28 18:14 ` Eric Voskuil
2018-08-28 18:36 ` Jonas Schnelli
2018-08-29 12:25 ` Blockchain Group
2018-08-29 14:40 ` Eric Voskuil [this message]
2018-08-29 16:06 ` Blockchain Group
2018-08-29 18:27 ` Jonas Schnelli
2018-08-29 18:29 ` Blockchain Group
2018-08-29 18:45 ` Eric Voskuil
2018-08-30 10:03 ` Aymeric Vitte
2018-08-30 11:40 ` Blockchain Group
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=dev@jonasschnelli.ch \
--cc=shekharhiran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox