public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonas Schnelli <dev@jonasschnelli•ch>
To: Eric Voskuil <eric@voskuil•org>
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.
Date: Wed, 29 Aug 2018 20:27:51 +0200	[thread overview]
Message-ID: <4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch> (raw)
In-Reply-To: <758E3CA7-295B-4B77-BFF5-9AAE959D53EA@voskuil.org>

[-- 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 --]

  parent reply	other threads:[~2018-08-29 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 19:58 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
2018-08-29 16:06     ` Blockchain Group
2018-08-29 18:27     ` Jonas Schnelli [this message]
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=4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch \
    --to=dev@jonasschnelli$(echo .)ch \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=eric@voskuil$(echo .)org \
    --cc=shekharhiran@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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