Re: [bitcoin-dev] Building a Bitcoin API and query system.

[Blockchain Group <shekharhiran@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

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 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.
>
> IMO an API that serves non verifiable data is supporting centralised
> validation. The „API" which supports one of the most important properties
> in Bitcoin – the ability to self-validate – is the data available 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), 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.
>
> Bitcoin-Core has all required features to partially „index“ data (called
> the wallet) and provides them via the RPC API. If you don’t need to serve
> thousands of wallets (which smells after centralised validation), selective
> 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 UTXOs
> only).
>
> 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 "light clients" in a way where no trusted layer is
> required (client <-> p2p network rather then client <-> API provider <->
> p2p network).
>
> I don’t 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
>

[-- Attachment #2: Type: text/html, Size: 2876 bytes --]