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

[Jonas Schnelli <dev@jonasschnelli.ch>]

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


> 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: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]